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Part 1 


Migration 


In this part, we introduce version-to-version migration concepts, and provide 
information about the three migration patterns. 
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Overview of migration 
strategy 


There has been an increased interest among Business Process Management 
(BPM) customers to migrate to the latest version of the BPM products. In this 
book, we discuss the migration planning and execution steps that customers will 
follow for a version to version migration of Business Process Management 
products to IBM WebSphere Dynamic Process Edition Server V7.0. 

In this chapter, we discuss the three migration methods available to the 
customers, and the ways to choose the right method. This chapter provides a 
sample migration planning checklist, which the customers will use during their 
migration phases. We also discuss different phases of the migration and the 
scenarios we are planning to cover in a step-by-step migration demonstration. 
This chapter also provides introductory information about the products packaged 
in WebSphere Dynamic Process Edition Server. 
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1.1 Product overview 


This section provides information about the products in the scope of this book. 
Distributed platforms support all of the Business Process Management products 
discussed in this section, while IBM z/OS supports WebSphere Process Server, 
WebSphere Enterprise Service Bus, and WebSphere Business Fabric. 

1.1.1 WebSphere Dynamic Process Edition Server 

WebSphere Dynamic Process Edition Server is a comprehensive offering of the 
IBM BPM Suite. It provides end-to-end BPM capabilities for businesses to adapt 
and response dynamically to changes in today’s rapidly changing business 
environments. WebSphere Dynamic Process Edition V7.0 includes the following 
products: 

► WebSphere Dynamic Process Edition Tool and Testing Pack 

- IBM WebSphere Business Modeler Advanced V7.0 

- IBM WebSphere Business Services Fabric Tool Pack V7.0 (bundles 
WebSphere Integration Developer V7.0 and WebSphere Business Monitor 
Development Toolkit V7.0) 

► WebSphere Dynamic Process Edition Server 

- IBM WebSphere Business Services Fabric Foundation Pack V7.0 (bundles 
WebSphere Process Server V7.0) 

- IBM WebSphere Business Monitor V7.0 

More information about WebSphere Dynamic Process Edition Server can be 
found at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m . wdpe . doc/Wel come/i c-homepage . html 


1.1.2 IBM Business Space powered by WebSphere 

Business Space provides a customizable and collaborative environment for 
monitoring, reviewing, and administering common business processes, such as 
human task flows, modeling, and performance indicators. Business Space is a 
browser-based graphical user interface that lets business users interact with 
content from products in the WebSphere Business Process Management 
portfolio. 
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Business users can view the content they want to see in the way they want to see 
it by creating mashups, which are combinations of Web applications (widgets) 
configured on the pages of a business space that provides content from multiple 
sources. 

The Business Space powered by WebSphere framework encompasses the 
following Version 7 BPM products: 

► IBM WebSphere Process Server 

► IBM WebSphere Business Monitor 

► IBM WebSphere Business Modeler 

► IBM WebSphere Business Modeler Publishing Server 

► IBM WebSphere Business Services Fabric 

► IBM WebSphere ESB 

► IBM WebSphere Integration Developer 

More information about Business Space is available at the following URL: 
http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.bspace. i c.mai n . doc/we 1 come/bspace_wel come.html 


1.1.3 WebSphere Business Modeler 

WebSphere Business Modeler helps you document, visualize, and analyze your 
business processes using industry standards and leading Business Process 
Management (BPM) powered by Smart Service-Oriented Architecture (SOA) 
technologies. 

More Information about the product is available at the following addresses: 

► http://publib.boulder.ibm.eom/infocenter/dmndhelp/V7.0r0mx/topic/com.i 
bm. btool s .model er . basi c . i nst . doc/i nstal 1 i ng/t_l aunch_pl atform.html 

► http : //publ ib. boulder. ibm.com/infocenter/dmndhelp/V7. OrOmx/topi c/com. i 
bm. btool s .model er . advanced .mai n . doc/wel come/dochome_adv . html 


1.1.4 WebSphere Integration Developer 

WebSphere Integration Developer is a development environment for end-to-end 
integration of your service-oriented application. It is the Eclipse-based tool for 
building SOA-based business process management (BPM) and integration 
solutions across WebSphere Process Server, WebSphere Enterprise Service 
Bus, and WebSphere Adapters. 
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More information about the WebSphere Integration Developer product is 
available at the following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wbit.hel p.mainwel come. doc/topi cs/wel come.html 


1.1.5 WebSphere Business Compass 

WebSphere Business Compass provides a comprehensive set of tools for 
business process modeling, BPM design, and modeling collaboration. This 
product was introduced in Version 7.0. 

More information about the product is available at the following address: 
http: //publ ib.boul der. i bm. com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .model er . col 1 ab. publ i sh . doc/wel come/home . html 


1.1.6 WebSphere Business Monitor 

WebSphere Business Monitor is a comprehensive business activity monitoring 
tool that provides a real time, end-to-end view of business process performance. 
It allows for business users to predict problems before they occur. Process 
events and data can be collected from a wide variety of sources, such as 
business applications running in the WebSphere Process Server runtime 
environment. This information is then presented in personalized dashboards for 
business users. 

WebSphere Business Monitor V7.0 has added the ability to link strategic 
organization goals to operational metrics, has capabilities to handle in-flight 
processes, and improves end-to-end process monitoring by capturing events 
from additional IBM middleware and applications. In addition, the installation is 
simplified due to the new wizard-driven topology configuration capabilities. 

More information about WebSphere Business Monitor is available at the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s. hel p. monitor. doc/home/home. html 
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1.1.7 WebSphere Process Server 


WebSphere Process Server is a business process integration server that has 
evolved from proven business integration concepts, application server 
technologies, and the latest open standards. WebSphere Process Server is a 
high-performance business engine to help form processes to meet business 
goals. 

More information about the WebSphere Process Server product is available at 
the following addresses: 

► Distributed platforms: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm. websphere. wps. doc/we 1 come_wps.html 

► z/OS 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
. i bm .websphere . wps . z . doc/doc/wel come_wps_tun . html 


1.1.8 WebSphere Enterprise Service Bus 

WebSphere Enterprise Service Bus (WebSphere ESB) provides the capabilities 
of a standards-based enterprise service bus. It is available as a stand-alone 
product, and is also included in WebSphere Process Server. 

WebSphere ESB manages the flow of messages between service requesters 
and service providers. Mediation modules within the ESB handle mismatches 
between requesters and providers, including protocol or interaction-style, 
interface, and quality of service mismatches. In an Service Component 
Architecture (SCA) based solution, mediation modules are a type of SCA 
module. The mediation modules perform a special role, and therefore have 
slightly different characteristics from other components that operate at the 
business level. 

Mediation components operate on messages exchanged between service 
endpoints. In contrast with regular business application components, they are 
concerned with the flow of the messages through the infrastructure and not just 
with the business content of the messages. Rather than performing business 
functions, they perform routing, transformation, and logging operations on the 
messages. The information that governs their behavior is often held in headers 
flowing with the business messages. The IBM SOA programming model 
introduces the service message object (SMO) data structure to support this 
pattern. 
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WebSphere ESB supports advanced interactions between service endpoints on 
three levels: 

► Broad connectivity 

► A spectrum of interaction models and qualities of interaction 

► Mediation capabilities 

The product supports connectivity between endpoints through a variety of 
protocols and application programming interfaces (APIs). 

More information about the product is available at the Information Center at the 
following address: 

http : //publ ib. boulder. ibm. com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. websphere. wesb.doc/doc/wel come_wps_ovw.html 


1.1.9 WebSphere Business Services Fabric 

WebSphere Business Services Fabric provides an end-to-end platform to rapidly 
assemble, deliver, and govern industry-focused composite Business Services in 
a SOA environment. A Business Service represents a business function whose 
behavior can be adapted at run time based on the current business situation and 
policy. These Business Services are assembled into modules whose life cycle is 
separated from the core processes, making manageability of complex BPM 
projects easier. 

WebSphere Business Services Fabric enables easy and fast governed change of 
business processes. It includes two software packages: 

► IBM Business Services Foundation Pack 

The Foundation Pack contains a runtime business service policy enforcement 
and building engine that enables dynamic assembly of intelligent Business 
Services. It is based upon WebSphere Process Server. 

► IBM Business Services Tool Pack 

The Tool Pack is integrated into the WebSphere Integration Developer, and 
includes a visual assembly environment for creating and managing intelligent 
Business Service models and policies. 

More information about the WebSphere Business Services Fabric product can be 
found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.ws.fabric.icmaster.doc/ic-homepage.htm 
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1.1.10 WebSphere Adapters 


An important aspect of today's business integration requirements is the need to 
use existing Enterprise Information System (EIS) assets in a heterogeneous, 
integrated enterprise. Whether the business need is to share business data 
across disparate EIS assets, automate business processes across EISs, connect 
new e-business applications to existing EISs, or provide users with access to EIS 
business data, there is a common requirement to provide interfaces to EISs. 
Adapters play a key role in the integration of applications by providing these 
interfaces using open standards. 

The IBM WebSphere Adapter portfolio is a generation of adapters based on the 
Java™ 2 Platform, Enterprise Edition (J2EE) standard. They enable managed, 
bidirectional connectivity and data exchange between EIS resources and J2EE 
components. WebSphere Adapters V7.0 are J2EE Connector Architecture (JCA) 
1 .5 and Enterprise Metadata Discover (EMD) 1 .2 compliant 

The IBM WebSphere Adapter portfolio includes the following application and 
technology adapters: 

► IBM WebSphere Application Adapters 

- JD Edwards EnterpriseOne 

- Oracle E-Business Suite 

- PeopleSoft Enterprise 

- SAP Software 

- Siebel Business Applications 

► IBM WebSphere Technology Adapters 

- Email 

- File Transfer Protocol (FTP) 

- Flat Files 

- IBM 

- JDBC 

- Lotus® Domino® 

More information about the WebSphere Adapters can be found at the following 
address: 

http : //www-01 . i bm. com/software/i ntegrati on/wbi adapters/1 i brary/i nfocent 
er/ 
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1.2 Terminology 


This section provides a description of some of the terminology that is helpful in 
understanding the information in this book: 

Migration versus upgrade Migration refers to the movement of a 

group of objects from one installation 
environment to another environment. This 
is required when delivering major new 
features, profile updates, and 
enhancements. This also applies to first 
and second digit release number changes. 
The new version must be installed 
side-by-side to the old version of the 
product. 

Upgrade refers to the replacement of a 
product with a newer version of that same 
product (also known as an in-place 
upgrade) This includes updates or fixes to 
the existing components. This applies to 
third and fourth digit release number 
changes (interim fixes, refresh packs, and 
Fix Packs). The new version is installed on 
top of the existing installation of the 
previous release. See 3.1.2, “Runtime 
migration versus an in-place upgrade” on 
page 85 for more details. 

There are three types of migration 
methods recommended by IBM. They are 
discussed in detail in 1.3, “Migration 
methods” on page 1 1 . 

The pre-migration deployment 
environment, which uses the earlier 
product version. 

Target cell The post-migration deployment 

environment, which uses the later product 
version. 

WAS_lnstall_root The root directory where WebSphere 

Application Server is installed. 

BPM_home The root directory where WebSphere 

BPM products are installed. 


Migration methods 


Current cell 


10 Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V 7 



Product databases 


This item refers to the databases used by 
the WebSphere BPM products. 

Application databases The databases used by user applications. 

Network deployment environment In this environment, the BPM components 
are configured in a high availability 
clustered environment. This can be set up 
as a single cell topology or a cross-cell 
topology. 

Artifacts This item includes the customer 

application with source and associated 
packages. All of them are imported into 
the new tooling environment to migrate 
them to the newer version of the product. 


1.3 Migration methods 

There are three types of version-to-version migration methods to choose from: 

► Runtime migration 

The runtime migration process replicates the source production configuration 
into the target environment. During the migration process, the target 
production environment replaces the source production environment, so the 
two environments are never operated in parallel. 

► Manual migration 

In this method, you are free to create a parallel target production environment 
that is configured from scratch differently than the source production 
environment. Applications can then be selectively redeployed from the source 
production environment to the target production environment. The redeployed 
applications create their own database tables and application data in the 
parallel production environment so they do not have access to the application 
data stored in the databases configured for the source production 
environment. 
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► Artifact migration 

Artifact migration method is similar to the manual migration method in terms 
of the configuration of the parallel target production environment, but instead 
of the applications being manually redeployed from the source environment 
directly into the target production environment, they are imported into the 
development environment and migrated by the development tools. The 
application can then be tested and deployed to the parallel target production 
environment. Consistent with the manual migration method, when the 
applications are deployed to the target production environment, they create a 
new set of database tables, so they do not have access to the application data 
stored in the databases configured for the source production environment 


1.3.1 Runtime migration 

In production environments, the runtime migration procedures and tools provided 
by the BPM products can be utilized to migrate topology configuration, 
applications, and databases to the new version. The runtime migration 
procedures and tools support both stand-alone and network deployment 
environment migrations, as well as variants that include: 

► Migration to a remote system (stand-alone environments only) 

► Migration while an operating system is being upgraded to a version 
(stand-alone environments only) 

► Network deployment variants to support full downtime migration and minimal 
downtime migration. 

The runtime migration process replicates the source production configuration into 
the target environment. During the migration process, the target production 
environment replaces the source production environment, so the two 
environments are never operated in parallel. 

When to use this migration method 

The runtime migration procedures and tools should be used in the following 
scenarios: 

► You want to move your applications to the new version without having a 
dependency on the development tools and the development environment. 

► You want to automatically have your source production environment 
configuration and applications replicated in the target production 
environment. 

► You have long-running processes or human task instances that have started 
in the source environment and need to complete in the target environment. 
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► You have product data in queues or failed events in product databases that 
were created in the source environment and need to survive the migration 
and be managed in the target production environment. 

► You can tolerate a production environment downtime window to perform the 
migration. 


WebSphere Adapters: If you use any WebSphere Adapters for Version 6.0.2 
or WebSphere Adapter for SAP Versions 6.0.2, 6.1.0, 6.1 .2, and 6.2.0, see 
2.6.3, “Known limitations for WebSphere Adapters” on page 79. 


Task overview 

The high level tasks involved in runtime migration are: 

1 . Install the new product version. 

2. Back up all production profiles and databases. 

3. Migrate each source environment profile to the target environment. 

4. Migrate or upgrade the product databases. 

5. Migrate the product database data. 

1.3.2 Manual migration 

An alternative to using the migration procedures and tools is to use the manual 
version-to-version migration process. With the manual migration process, you 
create a parallel target production environment that is separate from the source 
production environment. Applications can then be selectively re-deployed from 
the source production environment to the target production environment. The 
re-deployed applications use new database tables and application data in the 
parallel production environment, so they do not have access to the application 
data stored in the databases configured for the source production environment. 

When to use this migration method 

The manual runtime migration method should be used in following scenarios: 

► You want to move your applications to the new version without depending on 
the development tools and the development environment. 

► You want to reconfigure your topology as part of the process of migrating. 

► You do not have long running process instances and human tasks. 
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► You do have long running process instances, but can run parallel production 
environments while you drain the process instances and human tasks in the 
source environment as new instances are started in the target production 
environment. 

► You have application data in queues or failed events in product databases that 
were created in the source environment that can be managed to completion 
in the source production environment while new messages and events are 
routed in parallel to the target production environment. 

► You cannot incur any downtime in your production environment and can 
concurrently manage parallel source and target production environments. 

► You want to selectively redeploy applications from your source production 
environment to your target production environment. 

Task overview 

The high level tasks involved in manual migration are: 

1 . Install the new product version. 

2. Configure your desired parallel production environment. 

3. Manually deploy applications from the source environment to the target 
production environment. 

4. Optional: Run both environments in parallel so business process instances 
and human task instances that are in progress finish in the source 
environment and new instances start in the target environment. 

1.3.3 Artifact migration 

The artifact migration process is similar to the manual migration process in terms 
of the configuration of the parallel target production environment, but instead of 
the applications being manually redeployed from the source environment directly 
into the target production environment, they are imported into the development 
environment and migrated by the development tools. This process results in 
applications whose artifacts can be modified to exploit the new capabilities 
delivered by Version 7.0. The application can then be tested and deployed to the 
parallel target production environment. 

As with the manual migration process, when the applications are deployed to the 
target production environment, a new set of database tables are created. The 
applications do not have access to the application data stored in the databases 
configured for the current production environment. The database will have 
historical application data. Based on the schema changes in the user 
applications, the developers need to evaluate if the historical data can be 
imported into the new/target user application database. 
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When to use this migration method 

The artifact migration method should be used in the following scenarios: 

► You want to use the development tools to migrate the application artifacts to 
the new version and validate the compatibility of your applications. 

► You want to use the development tools to update your applications to exploit a 
new capability delivered by Version 7.0. 

► You want to reconfigure your topology as part of the process of migrating to 
the new version, or you can manually duplicate your source production 
environment configuration in your parallel production environment. 

► You do not have long running process instances and human tasks, or you can 
run parallel production environments while you drain the process instances 
and human tasks in the source environment as new instances are started in 
the target production environment. 

► You have application data in queues or failed events in product databases that 
were created in the source environment. These can be managed to 
completion in the source production environment while new messages and 
events are routed in parallel to the target production environment. 

► You cannot incur any downtime in your production environment and can 
concurrently manage parallel source and target production environments. 

► You want to selectively migrate applications from your source production 
environment to Version 7.0 with the development tools and selectively deploy 
those applications to your target production environment. 

Task overview 

The high level tasks involved in artifact migration are: 

1 . Install the new product version. 

2. Configure your desired parallel production environment. 

3. Import the applications from the source production environment into 
development tools and migrate the applications according to the development 
tool's migration procedures. 

4. Optional: Update the migrated applications to exploit new capability delivered 
in Version 7.0. 

5. Manually deploy the migrated applications from the development tools to the 
target production environment. 

6. Optional: Run both environments in parallel so business process instances 
and human task instances that are in progress finish in the source 
environment and new instances start in the target environment. 
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1.3.4 Choosing the right migration method 


This section contains information about how to decide the best migration method 
for a given customer situation. The analysis of cost, benefits, and risk analysis for 
the three migration methods is shown in Table 1-1 . 


Table 1 - 1 Migration cost benefit and risk analysis 


Method 

Benefits 

Cost 

Risks 

Runtime 

► Old configuration 

► Requires downtime. 

► Rollback might be 

migration 3 

moved/updated. 

► Dependency on 

needed in case of 


► Old applications moved 

migration tools. 

failures. 


as is. 

► All applications moved 

► Existing applications 


► Uses existing 

together. 

might not work 


databases, updated for 

► No exploitation of new 

because of upgraded 


new version. 

features. 

JDK versions or due to 


► Migration tools available. 

► Cannot be used for 

the use of 


► Can be used with long 

parallel production 

unsupported BPM 


running processes. 

environment.. 

product APIs. 

Manual 

► No dependency on 

► Cannot be used for 

► Existing applications 

Migration 

migration tooling. 

in-flight long running 

might not work 


► Can utilize existing 

processes. 

because of updated 


configuration scripts. 

► Needs a new database, 

JDK version or due to 


► Allows a parallel 

and the old data is not 

use of removed BPM 


production environment. 

brought into the new 

product APIs. 


- Selective application 

one. 



move. 

► No exploitation of new 



- No downtime. 

features. 



► Enables extensive 

► Requires updates to 



testing of new 

client applications. 



environment. 

► Additional licenses and 



► Regression tests are 

hardware cost (if running 



adequate. 

parallel). 
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Method 

Benefits 

Cost 

Risks 

Artifact 

Migration 

► Can exploit new 
features. 

► No dependency on 
migration tooling. 

► Can utilize existing 
configuration scripts. 

► Allows a parallel 
production environment 

- Selective application 
move. 

- No downtime. 

► Enables extensive 
testing of new 
environment. 

► Cannot be used for 
in-flight long running 
processes. 

► Needs a new database, 
and the old data is not 
brought into the new one 

► New tests for updated 
applications. 

► Requires updates to 
client applications. 

► Additional licenses and 
hardware cost (if running 
parallel). 

► Applications might not 
be interoperable with 
applications at older 
versions (EMF to XCI). 


a. If you use any WebSphere Adapters for Version 6.0.2 or WebSphere Adapter for SAP Versions 
6.0.2, 6.1.0, 6.1.2, and 6.2.0, see 2.6.3, “Known limitations for WebSphere Adapters” on page 79. 


The flow chart shown in Figure 1-1 can be used to help you decide which 
migration method will be suitable for your circumstances. WebSphere Business 
Process Management products have added several features in Version 7.0. You 
should read about these features in the Information Center to see how they apply 
to your situation. It is also a good idea to install the new version in a test 
environment to understand the differences between your current product 
versions and Version 7.0. This will help you with your decision making process 
for migration. 
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1.4 Scenarios demonstrated 

Because the number of version to version migration scenarios is very large, we 
have selected known and tested combinations and present them in 1 .5, 
“Migration best practices” on page 18. 

To illustrate a typical migration process, we provide two scenarios in this book. 
Both will show a migration from Version 6.1 .2 BPM products to WebSphere 
Dynamic Process Edition V7.0. The first scenario, shown in Chapter 6, “Migrating 
BPM V6.1 .2 to WebSphere Dynamic Process Edition V7.0” on page 195, shows 
the migration of a broader range of BPM products on a distributed base. The 
second scenario, shown in Chapter 7, “Migrating WebSphere Process Server 
V6.1 .2 to V7.0 on a z/OS system” on page 341 , shows the migration of 
WebSphere Process Server on a z/OS system. 

Both scenarios illustrate a migration where the pre-migration topology and the 
post-migration topology are the same. The topology used for the z/OS example is 
different from the topology used for the distributed example. 

We chose Version 6.1 .2 for our scenarios because many customers are using 
this release. It has the additional advantage of allowing us to illustrate the 
migration of some of the newer products to Version 7.0, including Adapters and 
Business Space. 

1.4.1 Assumptions and what is not covered in this book 

The scenarios use a runtime migration method where the migration will be 
completed in-place on the same hardware, to the same topology. The scenarios 
also assume that all the products will be migrated to WebSphere Dynamic 
Process Edition Server V7.0 


1.5 Migration best practices 

This section provides best practices for different phases of the migration project. 
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1.5.1 Planning 


The migration planning phase is very critical. It is usually longer than the 

migration execution phase. The time spent in collecting the necessary data will 

ensure a successful migration project. The best practices for the planning phase 

include: 

1 . Always plan ahead. Start the planning phase as early as possible in order to 
have time to collect all the relevant data. 

2. Collect information about the new features added since the current version of 
your product was installed. 

3. Install the new version of the product in a test environment to understand the 
differences and advantages. 

4. Prepare the migration planning checklist shown in 1 .6, “Migration 
questionnaire” on page 21 and complete it as you progress through the 
project. 

5. Designate a focal point for the migration project, who can involve the right 
people during migration phases. 

6. Use the “skills needed” list discussed in 1 .7.4, “Identify skills” on page 43 to 
identify the key needs. Plan to use IBM Education Assistance or other 
education services provided by IBM. Consider involving IBM software 
Services teams, who have a lot of experience in migrating WebSphere 
products. Plan ahead for their on-site and off-site assistance based on the 
availability of the systems. 

7. To ensure quick problem resolution, keep the focus on issues specific to 
migration. IBM provides a Management Alert facility, through which e-mails 
are sent to the support organization when IBM customers are performing a 
migration project. 

8. Keep a comprehensive test plan and execute the test plan before production 
migration and after production migration. 


1.5.2 Migration execution 

This section lists the best practices for the execution phase of the migration: 

1 . Document migration procedures. Keep track of the logs and FFDCs that will 
be part of the must-gather documents for problem determination. 

2. If you decide to use the runtime migration method, keep application migration 
as a separate migration project. 

3. Keep track of the migration steps performed, scenarios executed, and the 
associated migration logs. 
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4. Back up all the artifacts and profiles that are to be migrated. Keep the 
backups until the migration is complete and post migration tests are 
completed satisfactorily. 

5. Develop contacts in the IBM Software services team, IBM support teams, and 
among IBM Business Partners. Those qualified for migration projects will 
have access to the key contacts for migration questions. 

6. Keep the logs for the start of all JVMs and product install logs separate, so 
that it will be easier for problem determination. 

7. Start the migration project by evaluating and eliminating unused and 
depecated applications. 

8. BPM products come with sample applications and diagnostic applications, 
which, when installed, can help isolate any issues in the new environment. If 
you have a test application, use it after every phase of the migration. Build a 
list of verification tests to be run at different phases of the migration project 
and use them to verify the progress. 

9. All the operating systems support the silent migration procedures, while the 
GUI procedures are supported only on select platforms. In most of the 
production environments, only the silent procedure is allowed. 

10. Minimize human induced errors. You can use automation procedures using 
silent migration procedures. The script file thus built will have all the 
necessary migration steps and will ensure the sequence of the migration 
steps. 

1 1 .Use the roll back options to switch back to the earlier version, when needed. 
In early phases of the migration, you might need to switch back and forth 
quickly between versions in development or test environments. 

12. Create migration documents from the check list and early tests. Use them for 
the production environment migration. 


1.5.3 Post migration testing 

After the migration: 

1 . Keep the test and development environments as similar to the production 
environment as possible. 
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2. Performance tuning and testing are key phases of the migration project. To 
learn more about performance tuning information, refer to the following IBM 
Redpapers™ publications: 

- WebSphere Business Process Management and WebSphere Enterprise 
Service Bus V7 Performance Tuning, REDP-4664 

- WebSphere Business Process Management 6.2.0 Performance Tuning, 
REDP-4551 

- IBM WebSphere Business Process Management V6. 1 Performance 
Tuning, REDP-4431 


1.6 Migration questionnaire 

This section contains different check lists that are used for planning a migration. 
This list is based on a WebSphere Process Server migration check list that can 
be found at the following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2307&ui d=swg27015595 

The objective of the questionnaire is to help you determine your readiness to 
migrate and to point out areas where you might need additional help. 


Examples: Examples of completed check lists that make up this 
questionnaire can be found in Appendix A, “Migration checklist” on page 453. 
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1 .6.1 Reasons for migration 


The questions in Table 1 -2 are intended to help you decide if you want to migrate 
or upgrade, and to determine the type of migration that is appropriate. 


Table 1-2 Migration goal questions 


Migration goal questions 

Actions 

Do you want to use the features or functions 
provided in Version 7.0 of the product? 

What are the features you want to use? 

If you are planning to use the new features, you 
might need to perform an artifact migration. The 
list of features will also be a factor in deciding the 
type and time frame for the artifact migration. 

Do you want to be as up-to-date as possible with the 
latest of Business Process Management product 
versions and fixes? 

if you want a specific product fix or a Fix Pack, an 
upgrade will be more suitable. This implies that 
you are planning to use new features. You can 
choose to do. 

Are you migrating due to a current problem with any 
of the products? If so, what problem and what 
product? 

If the problem involves new features and if it 
involves changing the applications, then you will 
choose profile, application, and artifacts 
migration. 

What are the other reasons for migrating? 

This is another item to consider when deciding on 
the type of migration method. 
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1.6.2 Experience with migration 


The questions in Table 1-3 will help you determine the available skills level on 
hand and to plan for any additional help. At the end of this exercise, you should 
come up with a contact list of experts who can be contacted to answer questions 
about specific areas. You also should have a list of best practices based on 
previous migration experiences. 


Table 1-3 Migration experience questions 


Migration experience questions 

Actions 

Is this the first migration project for your team? 

If this is your first time to perform this migration, 
pay close attention to your planning. As you do not 
have historical data to compare, consult the 
Information Center and IBM’s migration best 
practice documentation to determine the timeline 
for the migration steps. We also recommend 
installing the product in a test environment to 
understand the new features and gain experience 
with the new version of the product. 

What WebSphere products have you migrated 
before? 

The migration strategy for BPM products is 
designed to be similar, so experience with earlier 
migrations of BPM products will help. 

What difficulties did you experience last time? 
What mitigation strategies are planned for this 
migration project? 

The lessons learned from previous migration 
experience can be used to avoid similar issues. 

What best practices from last time will you want to 
reuse in this migration project? 

The migration procedure for all products are 
similar and the best practices from a previous 
migration will be of great help in the current 
migration project. 

List of people with experience with WebSphere 
products, topology, business applications, security 
strategy, and migration experience. 

You need to build the list of Subject Matter Experts 
and administrators and their contact information to 
be used during execution phase. You can use the 
same list for a communication plan during the 
project. 
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1.6.3 Migration project plan 


Table 1-4 contains a list of questions that can help you determine the migration 
project milestones. Based on the information collected, negotiate an acceptable 
time frame to perform the migration. 


Table 1-4 Migration time frame 


Migration time frame related questions 

Actions 

What is the target date for starting the 
migration project? 

By this date, you must have completed any 
database upgrades or operating system upgrades 
needed for the migration project. By this date, the 
required hardware must also be made available. 

What is the target date for completing the 
migration project? 

This date, along with the start date, helps calculate 
the feasibility of the migration project. The available 
time should include migration of all the 
environments, testing, and performance tuning. 

Do you have a go live date, dictated by 
commitments to your customers? 

This item is important in planning the migration 
project. All the testing needed for the go live action 
needs to be completed by this date. 

What is the maximum downtime that is 
allowed for the migration? 

You need this information to determine the right 
migration method. 

Will the database and security administrators 
and application experts be available during 
the downtime period? 

These stakeholders have to be available during the 
migration time. DBAs and security administrators 
are key. Many enterprises follow a strict change 
management procedure. If this is in place, the 
approval process during the migration time is 
critical to avoid any delay. 
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1.6.4 Types of migration 


The answers to the questions in Table 1-5 will help you determine exactly what 
you will be migrating. These answers can influence the migration strategy to be 
used. They can also help you calculate the time needed for the different 
migration tasks. Use Table 1-5 to build a list of items to migrate and when they 
need to be done. 


Table 1-5 What to migrate 

| Questions about what to migrate 

| Actions [ 

| Profiles | 

1 . Do you have applications that can be migrated 
as is? Can all of your applications be migrated 
without upgrades? 

2. Do you have the current and target environment 
on the same hardware? 

3. Do you have to migrate the deployment 
environment, including deployed applications? 

4. Have you verified that the operating system 
used, database used, and their release levels 
are supported by both current and target 
environment? 

If you answered “yes” to the first three questions, 
use runtime migration. 

Verify that your target migration environment is a 
supported operating environment. This includes 
the hardware platform, the operating system, and 
the database. 

Download all the product install images and the 
latest fix packs. Validate that there is sufficient 
storage on the system. 

| Deployed applications | 

1 . Do you have applications that can be migrated 
as is? These are applications that will not be 
using any new features in the new release. 

2. Do you have long running business processes? 

3. Do you have human tasks? 

4. How many applications are used in the system? 

5. How many applications are business critical? 

6. How many applications can be deprecated? 

7. How many applications will have to be updated 
to use new features of the product? 

8. How many Monitor Models are deployed? 

9. How many Fabric associate applications are 
deployed? 

If there are applications that can be migrated as is, 
you should use the runtime migration method for 
them. 

Answers to questions 3 to 7 help with planning 
and scheduling during migration. 
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Questions about what to migrate 

Actions 

Application source 

1 . Do you need to migrate the source for any 
applications? 

2. Are these user applications included in the 
production critical time line? 

3. Do you have deprecated features? A list of 
these features is available at the following 
address: 

http : //publ i b . bout der . i bm. com/i nfocenter/d 
mndhel p/V7. OrOmx/topic/com.ibm. websphere. w 
ps . doc/doc/gmi g_deprecati onlist.html 

1 . Migrating the application source requires 
artifact migration. If you want to use the new 
features available in the new version of the 
product, you need to import the source to IBM 
WebSphere Integration Developer V7.0 and 
make the necessary modifications. 

2. If applications that are marked for artifact 
migration can be migrated on a separate time 
line, the migration project can be separated 
accordingly. 

3. If your applications have deprecated features, 
we recommend using artifact migration and 
also follow the procedures indicated in the 
Information Center, which can be found at the 
following address: 

http : //publ i b . boul der. i bm.com/ i nfocenter 
/dmndhel p/V7 . OrOmx/topi c/com. i bm.websphe 
re . wps . doc/doc/cmi g_vtv_mi gtypes . html 

Profile, deployed applications, application 
source, Monitor data migration 

Profile, application, data migration 

You might have a combination of needs that require 
manual migration of profiles, applications, and other 
artifacts. 

There will definitely be a need for manual 
migration in this case. Discover what items can 
use the migration APIs. It is also important to 
evaluate what can be done in parallel. 
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1.6.5 Migration downtime 


Use Table 1-6 and the information in this section to decide upon the downtime 
planned for your migration. 


Table 1-6 Downtime questions 


Downtime questions 

Actions 

Do you have business critical applications that 
need to be run continuously? 

If you have such applications, you should look at 
migration methods with minimum downtime. 

What is the maintenance window for such 
applications? 

Migration execution can be planned based on the 
maintenance window. 

Do you have long running processes in these 
applications? 

If you have business critical applications that 
require a minimal downtime and have a long 
running process, you need to choose the manual 
migration method. 


Downtime means that work has been quiesced and the servers are stopped. 
Among BPM products, the following products are more affected by downtime 
than other products: 

► WebSphere Process Server will be impacted the most, because mission 
critical applications run on WebSphere and the users expect minimum or no 
downtime. WebSphere Enterprise Service Bus has similar issues. 

► WebSphere Business Monitor and the associated Business Space will have 
downtime when the servers are down. The impact is that there are no 
dashboards displayed. Events might accumulate, and you need to plan for the 
consumption of these events after the migration is complete. 

► The impact to WebSphere Business Fabric is similar to WebSphere Business 
Monitor and Business Space. 

WebSphere Integration Developer, WebSphere Business Modeler, and 
WebSphere Compass Server are not affected by downtime very much, because 
they are tools and their use can be staggered. 

The manual migration method uses parallel environments, both running 
concurrently in the same hardware. The applications are not modified, so with 
both environments running, this method has the least downtime. 

The artifact migration method uses parallel environments, both running 
concurrently in the same hardware. While both environments are active, the 
client applications can be modified and we can arrange for the right version to 
handle proper routing. Although it requires additional work to prepare 
applications, this methodology minimizes downtime. 
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The manual and artifact migration methods will not use the same hardware. The 
target environment can be prepared while the current environment is active. The 
current database tables are updated and used for the target cell. There will be 
downtime to update the database table and this downtime can be incurred all at 
once or it can be phased. 

Migrating with full downtime 

Full downtime means that all the JVMs (the deployment manager, all node 
agents, all cluster members, and all servers) and all applications are stopped. 
The migration is performed, all of the database tables are updated, and then all 
the JVMs are restarted in the recommended sequence. This is the more 
common scenario. You can learn more about this migration by going to the 
following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps.doc/doc/tmig_vtv_ndful 1 .html 

Migrating with minimal downtime 

When migrating with minimal downtime, the goal is to minimize the amount of 
time the entire system is down. This procedure involves spacing out actions 
across multiple maintenance windows. Initially, part of the clusters are migrated; 
the rest of the nodes can be migrated at a later point of time, after the first set of 
nodes is up and running successfully. This action requires that each cluster have 
at least two members. This action impacts performance and throughput and 
needs to be negotiated with the customers. You can learn more about this 
migration by going to the following address: 

http: //publ i b.boul der. i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. websphere. wps.doc/doc/tmi g_vtv_ndmin.html 
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1.6.6 System maintenance procedures 


As a part of your migration planning, you should document the normal system 
shut down and restart procedures and schedule. This will help plan downtime 
during migration. Table 1-7 helps you collect the relevant information. 


Table 1-7 System maintenance questions 


System maintenance questions 

Actions 

Is the system maintained on a regular 
schedule? 

If the answer is “yes”, this scenario gives you an 
opportunity to do migration procedures during this 
time and minimize downtime. 

What is the schedule? 

Make sure all the stake holders and other 
resources are available during this window, which 
can be used for migration. 

How is the system shut down? 

What is the procedure and in what order are the 
components shut down? 

The recommended shutdown sequence is: 

1 . Dashboard clusters. 

2. Application clusters. 

3. Support clusters. 

4. Message engine clusters. 

5. Node agents. 

6. Deployment manager. 

How is the system restarted? 

What is the procedure and in what order are the 
components restarted? 

The recommended start sequence is: 

1 . Verify that the database is available. 

2. Start the deployment manager. Verify by 
checking SystemOut .log. 

3. Start the node agents. Verify. 

4. Start the message engine cluster. Verify. 

5. Start the support cluster. Verify. 

6. Start the applications cluster. Verify. 

7. Start the dashboard clusters. 

Will the DBA be available during this scheduled 
maintenance? 

Is any special security clearance required for 
executing database scripts? 

Because we need the help of the DBA, the 
availability and approval of the DBA to run 
database scripts is necessary. 

Will the security administrator be available 
during this maintenance window? 

You will need assistance from the security 
administrator. 

Will the network administrator be available and 
can the ports needed for BPM components and 
applications be opened during this period? 

New ports might be needed based on your 
applications, so we need clearance to complete 
this task. 
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1.6.7 Resource availability 

It is important to identify the resources for the migration project. The resources 
include: 

► Subject matter experts 

► Database administrators 

► Security experts 

► Network administrators 

► Migration experts 

► Application experts 

► Migration documents 

► Hardware 

► Product licenses 

► Architecture and topology information 

► Sample and diagnostic models 

► A test plan 

Table 1-8 is an example of the information that needs to be updated and 
maintained during the migration process. 


Table 1-8 Resource availability 


Resource question 

Identified resource 

Resource availability 

Who will be the dedicated 
resource for the migration 
project? 

Migration project manager 


Do you have reusable assets 
from previous migration efforts? 

Automated migration test bucket 


Who are the dedicated 
resources for: 

Migration method 


Migration testing 



Environment creation 



Applications 



Profiles 



Database 



Operating systems 



Network and firewall 



Your software process 
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Resource question 

Identified resource 

Resource availability 

Name of the migration expert or 
consultant 



Hardware resource 

(Verify that there is adequate 

hardware.) 

Cell name 


System type 


Memory 


Operating system 


Disk space 


IP address 


Remote access capability 


Software licenses 

For IBM products and others 



1.6.8 Product versions 

You need to document the current and target versions of the products that will be 
migrated. This information can be entered into Table 1-9. 


Table 1-9 Products and versions 


Product 

Current version 

Target version 

WebSphere Dynamic Process Edition server 



WebSphere Process Server 



WebSphere Application Server associated 
with WebSphere Process Server 



WebSphere Integration Developer 



WebSphere Business Modeler 



WebSphere Business Fabric 



WebSphere Business Monitor 



WebSphere Application Server associated 
with WebSphere Business Monitor 



WebSphere Compass Server 



WebSphere Enterprise Service Bus 



Business Space 
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Product 

Current version 

Target version 

WebSphere Portal Server 



WebSphere Service Registry and repository 



Database 



Operating System 



JDBC version 




1.6.9 Product maintenance 

It is important to apply the latest available Fix Pack for the target release and also 
any important ifixes. 

Table 1-10 shows where the latest IBM recommended Fix Packs and fixes are 
located. 


Table 1-10 Product maintenance information 


Product 

Fix Pack information 

WebSphere Dynamic Process 
Edition server 

http://www-01.ibm.com/support/docview.wss?uid=swg2 1415947 

WebSphere Process Server 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27006649 

WebSphere Application 
Server 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27014463 

WebSphere Integration 
Developer 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2308&ui d=swg270 
06685 

WebSphere Business Modeler 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=4186&ui d=swg270 
17432 

WebSphere Business Fabric 

http: //www-01. ibm. com/support/docvi ew.wss?uid=swg2 1404766 

WebSphere Business Monitor 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27010921 

WebSphere Compass Server 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=4186&ui d=swg240 
25514 

WebSphere Enterprise 
Service Bus 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27007485 

Business Space 

No separate interim fix or Fix Pack. It will be included in the base 
component. 
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Product 

Fix Pack information 

WebSphere Portal Server 

http: //www-01. ibm.com/support/docview.wss?uid=swg27014411 


1.6.10 System requirements 

Identify the system requirements for the current cell and the target cell and 
mitigate any issues. The team should check the versions of the software 
products used by different BPM products and check for compatibility. 

Use Table 1-11 to track the version of the software products used by BPM 
products. 


Table 1-11 System requirements 


Software type 

BPM product 

Detail 

Current 

version 

Target 

version 

Database 

WebSphere 
Process Server 

Common DB (WPRCSDB), BPC 
tables (BPEDB), Message 
Engine DB (MEDB), and 
Common Event Infrastructure 
tables (EVENT) 

Depends on 
the current 
version 

DB2® V9.5 
or V9.7 

WebSphere 

Business 

Monitor 

Monitor database 

Depends on 
the current 
version 

DB2 V9.5 or 
V9.7 

WebSphere 
Service Registry 
and Repository 

WebSphere Service Registry 
and Repository database 

Depends on 
the current 
version 


WebSphere 
Business 
Service fabric 

WebSphere Business Service 
Fabric database 

Depends on 
the current 
version 


Operating 

system 

Server 

environment 




Tooling 

Environment 




Database node 
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Software type 

BPM product 

Detail 

Current 

version 

Target 

version 

Light weight 

Directory 

Access 

Protocol 

(LDAP) 

WebSphere 
Process Server 




WebSphere 

Business 

Monitor 




WebSphere 
Business Fabric 




Web server 

WebSphere 
Process Server 




WebSphere 

Business 

Monitor 




WebSphere 
Business Fabric 




Java Message 
Service (JMS) 
provider 





WebSphere 

Portal 
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1 .6.1 1 Workload characteristics of the current environment 


It is important to identify the workload of the environment. This information will 
help you discover the relevant Information Center information, Fix Packs, or 
APAR information, and also help you with performance tuning. Some of the 
information might affect the migration methodology discussed in 1 .6.4, “Types of 
migration” on page 25. The data is collected in Table 1-12. 


Table 1-12 Workload characteristics 


Category 

Characteristic 

Description 

Functionality 

Business Process Execution Language (BPEL) 

Number of applications and 
details 

Number of long running processes 


BPEL microflows 


Human tasks 


Business State machines 


SCA modules 


Maps 


Mediations 


Business rules 


Common Event Infrastructure used for WebSphere 
Business Monitor 


Common Event Infrastructure used for Business 
Process Choreographer Observer function 


Other Common Event Infrastructure usage 


Web Services 


Adapters: (SAP) 


Adapters: (JDBC) 


Adapters: (File) 


Adapters (Siebel) 


Adapters (Others) 


Other functions used 
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Category 

Characteristic 

Description 

Interaction 

styles 

Web services: JMS 


Web services SCA 


Interactions: Synchronous 


Interactions: Asynchronous 


Dependencies 
and sharing 

Dependencies among deployed Module 


Do you use a shared library? 


Workload 

volume 

Number of new process instances started per 
second, minute, or day 


Duration of average long running process instance 


Number of users supported by the system 


Number of transactions per second, minute, or day 


Number of monitor models 


Number of KPIs 


Number of measures 


Number of counters 


Number of cubes 


Amount of historical data 


Usage of REST service 


Dashboard usage 


Other 


Quality of 
service (QOS) 

Quality of service considerations 
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Category 

Characteristic 

Description 

Current 
Performance 
tuning settings 

WebSphere Application Server 


WebSphere Process Server 


WebSphere Enterprise Server Bus 


WebSphere Business Monitor 


WebSphere Business Fabric 


WebSphere Business Compass 


Other products 



1 .6.1 2 Deployment environment topology 

The topology recommended by each product has changed in some releases. 
Depending on which release you are migrating from, the topology differences 
might be significant. Use the current best practices. The information for 
WebSphere Business Process Management V7.0 Production Topologies is 
available in WebSphere Business Process Management 1/7 Production 
Topologies, SG24-7854. You can also find this boo at the following address: 
http://www.redbooks.ibm.com/redpieces/abstracts/sg247854.html ?0pen 

Other information related to the topology should be gathered for migration 
planning and execution, as shown in Table 1-13. 


Table 1-13 Topology 


Topology questions | Details 

Profile 

What type of topology is used? 

Stand-alone or network 
deployment environment? 
Description of the topology 
used. 

What is the name (host name) of the system of deployment manager 
node? 


What are the names (host names) of the systems hosting the other 
nodes? 


What is the type of hardware used for the deployment manager node? 


What is the type of hardware used for the deployment manager node? 
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Topology questions 

Details 

What are the profiles to be migrated? 


Where are the backups for the current profiles? 


Where are the backups for database backup? 


| Cluster | 

Do you have a WebSphere Process Server support cluster? (name 
and nodes for cluster members) 


Do you have a WebSphere Process Server message engine cluster? 
(name and nodes for cluster members) 


Do you have WebSphere Process Server application clusters? (name 
and nodes for cluster members) 


Do you have a WebSphere Business Monitor support cluster? (name 
and nodes for cluster members) 


Do you have a WebSphere Business Monitor message engine 
cluster? (name and nodes for cluster members) 


Do you have WebSphere Business Monitor application clusters? 
(name and nodes for cluster members) 


Do you have WebSphere Business Monitor Web clusters? (name and 
nodes for cluster members) 


Security 

What security strategy issued? | 

Other 

Do you have proxy servers? 


Firewall or other security information. 


Ulimit setting. 
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1.7 Migration road map 


This section describes the different phases of migration and the steps for each of 
them. We use the flow chart shown in Figure 1-2 to describe the migration road 
map. 



Figure 1-2 Migration road map 

The road map has the following phases and steps: 

1 . The preparation and planning phase will include the following actions: 

- Assessment 

- Choosing the migration method 

- Identify the resources needed 

- Identify skills 
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2. The testing phase includes the migration of the test environment and 
completing the tests to ensure that the test migration is successful. 

- Test run of migration (proof of concept) 

3. After the test run of migration, the production migration is planned: 

- Production migration 

4. Finally, the verification phase includes: 

- Verification of production and review 

We also recommend an analysis phase, where the best practices of the 
migration and the lessons learned are documented for future use. 

1.7.1 Assessment 

The assessment phase includes activities that help you determine your migration 
objectives, perform a system analysis, and assess your topology. 

Migration objectives 

Before you decide to migrate, complete a set of assessment questions (see 
Table 1-2 on page 22). This action will help you decide the migration method. 
Initially, you need to analyze the objectives of the migration. 

If you want to use the new features available in Version 7.0 and you need those 
features immediately, then you need to include artifact migration in your plan. 

If you do not need the new features, or at least not immediately, then you can 
migrate using other methods and plan to update the applications to use the new 
features at a later date. Applications can be updated one at a time to minimize 
the downtime. 

System analysis 

► Hardware requirements 

- You can use existing hardware with upgrades or you must use new 
hardware. 

► Software requirements 

- There might be changed specifications. 

- There might be dependencies between applications. 

- There might be API deprecation or removal and JDK changes. 

- There might be vendor applications and WebSphere products 
J2EE/JDK/Process Server version requirements. 
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Next, you need to look at your hardware requirements. This step will help you 
plan the hardware resources. Operating system upgrades might be necessary as 
a prerequisite to migration. You also need to download the product software and 
allocate sufficient hardware. You will also need to download the latest Fix Packs 
for the new system. Table 1-14 provides the URLs to the system requirements for 
all the BPM products. 


Table 1-14 System requirements 


Product 

Requirement information URL 

WebSphere Dynamic Process 
Edition server 

http : //www-01 . i bm.com/software/ i ntegrati on/wdpe/requi rements/ 

WebSphere Process Server 

http : //www-01 . i bm. com/support/docvi ew.wss?ui d=swg27006205 

WebSphere Application Server 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=180&ui d=swg270069 
21 

WebSphere Integration 
Developer 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2308&ui d=swg27006 
409 

WebSphere Business Modeler 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2025&ui d=swg27008 
331 

WebSphere Business Fabric 

http : //www-01 . i bm.com/ software/i ntegrati on/wbsf/sysreqs/ 

WebSphere Business Monitor 

http: //www-01. ibm. com/support/docvi ew.wss?rs=802&context=SSSRR 
3&uid=swg27008414 

WebSphere Compass Server 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2331&ui d=swg27008 
946 

WebSphere Enterprise Service 
Bus 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27006912 

WebSphere Portal Server 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27007791 


Topology assessment 

► Runtime environment configuration 

► Long-running processes 

► Downtime tolerance 

It is important to make an assessment of topology needs in the target 
environment. The migration questionnaire in 1 .6, “Migration questionnaire” on 
page 21 can help you collect data about the topology needs, how the products 
are used, and what your strategy should be for downtime during migration. You 
will identify migration needs, decide what can be done in parallel, and assess 
resource availability during this process. 
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The migration best practices recommends keeping a copy of the old tooling 
environment until all the applications are versioned using the new tooling 
environment. 

You should plan and perform backups of all the profiles and the database of the 
current environment. 

1.7.2 Choosing the migration method 

Choosing the migration method to be used is a critical step in the migration 
process. If you decide to use the same hardware and OS used in the current 
version of the products, and if you want to migrate configuration, data, and 
applications, then you should choose runtime migration (discussed in detail in 
3.1, “Overview” on page 82). 

If you want to use new hardware for the target environment, or if you want to 
change the topology in the target environment, choose manual migration 
(discussed in detail in Chapter 4, “Manual migration” on page 117). In this case, 
there will be not be any database or process instance migration. There will not be 
any profile migration. 

Artifact migration is needed if you want to use the new features in the new 
release. The options available to execute this method are discussed in detail in 
Chapter 5, “Artifact migration” on page 123 

1.7.3 Identify the resources needed 

In this phase, you assemble a core migration team. This team includes a 
migration coordinator or project manager, migration experts, product experts, 
application experts, system administrators, database administrators, key 
developers, performance experts, testing experts, security experts, and system 
maintenance experts. If, during this resource planning, you identify any skill gaps, 
work with the IBM team to arrange any education needed, or involve IBM 
software services. 

You need to plan for the hardware resources needed, any software prerequisites, 
and software upgrades. Plan for backups and develop a rollback plan. Other 
resources to plan for include time line charts, standard practices, automation 
scripts, regression testcases, system maintenance windows, and procedures. 
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1.7.4 Identify skills 


In this section, we list some of the common skills needed for migration. Additional 
skills might be needed based on the project and environment. 


Table 1-15 Skills Inventory 


Skills 

Needed (Y/N) 

Contact 

Migration methodologies 



Installation of BPM products 



Configuration of BPM products 



Hardware expertise 



Operating system expertise 



Network configuration expertise 



Database expertise 



Application expertise 



WebSphere Dynamic Process Edition expertise 



WebSphere Process Server expertise 



WebSphere Integration Developer expertise 



WebSphere Business Compass expertise 



WebSphere Application Server expertise 



WebSphere Business Modeler expertise 



WebSphere Business Fabric expertise 



WebSphere Business Monitor expertise 



WebSphere Enterprise Service Bus expertise 



WebSphere Adapter expertise 



Business Space expertise 



Security experts 



System maintenance experts 



Test experts 
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1.7.5 Test run of migration (proof of concept) 


Perform migration in the development environment or test environment before 
performing the migration in the production environment. The development or test 
environment should be similar to the production environment. 

During the test run phase, after performing the migration on the development or 
test environment, test your applications in a new environment first. Practice your 
rollback plan on a test system. If applicable, migrate the test systems iteratively. 
Complete all the planned post migration on this environment and document the 
results of the test cases. The document containing the test results will be used for 
comparison during the migration of production. 

Measure the time needed for each step of the test migration. This data can be 
used to verify the plans for production migration. 

1.7.6 Production migration 

After completing the test run of the migration, make any modifications necessary 
in the migration plan. If there are any schedule changes based on the migration 
time measured in the test migration, verify the availability of the resources in the 
new time schedules. Complete the migration using the planned method and the 
migration document created or updated during the test migration. 

After the production migration, run a quick set of regression tests to verify the 
success, and, if necessary, execute rollback procedures. 

1.7.7 Verification of production and review 

At this stage, you are done with the migration process and need some 
verification before starting the production environment: 

► Review the results of the migration. 

► Check the migration logs to make sure that there are no errors. 

► Complete any performance tuning needed after migration. 

► Complete all your standard test processes. 

► Perform rollback, if necessary. If the rollback is performed, consider that any 
new data stored after migration will be lost (for example, newly created 
business processes). 
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1.8 Post migration 


After migration, run a series of tests to ensure that the migration was successful. 
This is necessary before going into production mode. In addition, each of the 
BPM products has a set of post migration steps. 


1 .8.1 Post-migration steps for WebSphere Process Server 

Information about post-migration steps for each product component can be found 
in the appropriate Information Center article: 

► Information about post migration tasks for WebSphere Process Server is 
located in the Information Center at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . doc/doc/tmi g_vtv_post . html 

► Information about post migration tasks for WebSphere Business 
Choreographer is located in the Information Center at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . doc/doc/tmi g_vtv_post . html 

► Information about post migration tasks for Business Space powered by 
WebSphere is located in the Information Center at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm. websphere. wps. doc/doc/tmi g_vtv_post_bspace.html 

► Information about post migration tasks for WebSphere Enterprise Service Bus 
is located in the Information Center at the following address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm. websphere . wesb . doc/doc/tmi g_vtv_post . html 


1.8.2 Post-migration steps WebSphere Business Fabric 

The post-migration steps for WebSphere Business fabric for distributed platform 
is available at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m.ws .fabri c.mi gr .doc/mi gr70/task/t_veri fymi g .html 

The post-migration steps for WebSphere Business Fabric on the z/OS platform is 
available at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m.ws .fabri c.mi gr .doc/mi grzos70/task/t_veri fymi g . html 
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Release-specific information 


In this chapter, we discuss migration process differences based on your current 
version of the Business Process Management (BPM) product. We also discuss 
any known limitations when migrating from a previous release. 
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2.1 Product availability table 

Table 2-1 gives information about the availability of each WebSphere Business 
Process Management product. It provides a mapping of the BPM release and 
product availability. 


Table 2- 1 Product and version matrix 


Product 

V6.0.2 

V6.1 

V6.1.2 

V6.2 

V7.0 

WebSphere 

Application 

Server 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 

Process 

Server 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 

Integration 

Developer 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 

Business 

Monitor 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 
Business 
Monitor Toolkit 

Combined with 
WebSphere 
Business 
Monitor 

Combined with 
WebSphere 
Business 
Monitor 

Combined with 
WebSphere 
Business 
Monitor 

Combined with 
WebSphere 
Business 
Monitor 

Yes 

WebSphere 

Business 

Modeler 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 
Enterprise 
Service Bus 

Yes, part of 
WebSphere 
Process 
Server 

Yes, part of 
WebSphere 
Process 
Server 

Yes, part of 
WebSphere 
Process 
Server 

Yes, part of 
WebSphere 
Process 
Server 

Yes, part of 
WebSphere 
Process 
Server 

WebSphere 

Business 

Services 

Fabric 

Yes 

Yes 

Yes 

Yes 

Yes 

WebSphere 

Business 

Compass 

No 

Modeler 

Publishing 

Server 

Modeler 

Publishing 

Server 

Modeler 

Publishing 

Server 

WebSphere 

Business 

Compass 
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Product 

V6.0.2 

V6.1 

V6.1.2 

V6.2 

V7.0 

Business 

Space 

No 

No 

Yes 

Yes 

Yes 

WebSphere 

Dynamic 

Process 

Edition 

No 

No 

No 

Yes 

Yes 


2.2 Special considerations for migration from V6.0.2 

This section contains information specific to migrating from BPM V6.0.2 to 
WebSphere Dynamic Process Edition V7.0. Each section contains specific 
information pertaining to a BPM product for a Version 6.0.2 to Version 7.0 
migration. 


2.2.1 IBM Business Space powered by WebSphere 

The Business Space product was not available in Version 6.0.2. Portal-based 
dashboards were used instead. There are procedures required to either upgrade 
WebSphere Portal Server or to configure Business Space to use Portal’s 
dashboards or web-based dashboards provided by Business Space. Information 
about configuring Business Space is available at the following address: 
http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wbpm. bspace. confi g .doc/doc/tcon_conf i g_bspace.html 


2.2.2 WebSphere Business Modeler 

WebSphere Business Modeler requires only artifact migration. To migrate 
projects exported from Version 6.0.x, 6.1 .x, or 6.2.x (the .mar files), you can use 
the IBM WebSphere Business Modeler Version 7.0 import function. For more 
information , go to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s. model er. bas i c. i nst. doc/mi grating/i mportv6project.html 

The steps for importing and migrating models can be found in 5.2, “Migrating 
WebSphere Business Modeler models” on page 125. 
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Migrating projects stored in a team repository 

When you use IBM WebSphere Business Modeler Version 7.0 to check earlier 
Version 6 projects out from your version control system (for example, CVS), 
WebSphere Business Modeler automatically migrates such projects. 


Important: Before migrating, make sure that no Version 7.0 projects have the 
same name as the project that you want to migrate. If any Version 7.0 project's 
name matches the name of the project in the earlier version's team repository, 
you will not be able to connect to the earlier version's project to migrate it. The 
online help has additional information about setting up and using team 
repositories for versioning projects. 


When you migrate a Version 6.x project stored in the version control repository, 
WebSphere Business Modeler creates a copy of the project in your workspace 
and migrates that copy. The original project remains unaffected. 

To migrate the Version 6.x project stored in a team repository, perform the 
following steps: 

1 . Right-click anywhere in the Project Tree view of WebSphere Business 
Modeler Version 7.0 and select Version ->• Check Out Project. The Check 
Out Project wizard opens. 

2. Expand the CVS or ClearCase® node. 

3. Expand the repository that contains the project that you want to migrate. 

4. Select the project. 

5. Click Finish. A window opens, prompting you to confirm that you want to 
migrate the project. Click Yes. A local copy of the project is created and 
migrated for use with Version 7.0 

In case errors were introduced during migration, use the Errors view to validate 
the process models. If any errors occurred, fix the errors. 

A migrated copy of the project now resides in the workspace on your computer. 
Note that there is no connection between the migrated project and the original 
project in the team repository. In addition, you cannot add a connection, because 
the projects were made by different versions of WebSphere Business Modeler. 

If you want to continue sharing the migrated project, rename it and share it again 
using a new repository. 
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Tip: Set up separate team repositories for projects created with earlier and 
later versions of WebSphere Business Modeler. Earlier versions of 
WebSphere Business Modeler cannot access process models that have been 
shared using a later version of the product. A Version 7.0 project can be 
shared only using WebSphere Business Modeler V7.0. 


Migrating projects from a workspace 

The first time IBM WebSphere Business Modeler V7.0 accesses a workspace 
that contains projects created in an earlier version, IBM WebSphere Business 
Modeler V7.0 automatically migrates the entire workspace and its projects to 
Version 7.0. 

During this migration, a backup of the original workspace is created, and you can 
access the original process models again, if needed. 

Note that after migrating the workspace to WebSphere Business Modeler V7.0, 
the workspace cannot be accessed again using an earlier version. In addition, 
any projects shared using a team repository have their connection to that 
repository broken. 

To migrate projects stored in your workspace, perform the following steps: 

1 . Start the WebSphere Business Modeler product. 

2. When prompted to specify a workspace, specify the workspace that you want 
to migrate. 

3. Click OK to open the Migrate Workspace window. 

Note that WebSphere Business Modeler Basic V7.0 cannot migrate a 
workspace that contains projects created with earlier versions of WebSphere 
Business Modeler Advanced. 

4. Specify a backup location for the workspace. Ensure that the location you 
specify has enough space to store the backup copy. Otherwise, the migration 
will fail. If the migration fails because a backup cannot be created, the original 
workspace is not affected. 
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5. Optional: If you are working on a system that has English as its language and 
want to save space, select Backup as compressed file. 

Important: If any of the paths in your workspace contain non-English 
characters, including accented English characters, do not use the Backup 
as compressed file option. Non-English characters cause problems when 
extracting the backup files. If you do not know whether your workspace 
paths contain any non-English characters or not, use the default backup 
option. After the workspace migration completes, you can compress the 
backup files using the program of your choice. 

6. Click OK. The migration is now complete and the program restarts, accessing 
the newly migrated workspace. A window opens, listing both the projects that 
migrated successfully and the ones that did not. Messages are provided for 
any problems with migrating projects. 

7. To make sure no errors were introduced into your models during the 
migration, use the Errors view. If any errors occurred, fix the errors. 

Your workspace and all its projects are now migrated for use with WebSphere 
Business Modeler V7.0.lf you have another Version 6.x workspace that you want 
to migrate, restart WebSphere Business Modeler V7.0 and access that 
workspace to migrate it. 

2.2.3 WebSphere Business Compass 

The following information is available in the Information Center at the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s . hel p .model er . col 1 ab. publ i sh .mi g . doc/mi g/mi grate_602 . html 

After installing WebSphere Business Compass, you can use the scripts that are 
provided to help you migrate your data from WebSphere Business Modeler 
Publishing Server V6.0.2. 

Before beginning the migration, verify that the following tasks have been 
completed: 

► Back up the following LotusDomino databases: 

- WBICOLWIPComment.nsf 

- WBICOLWIPModel.nsf 

- WBICOLReleaseModel.nsf 

► Ensure that the LotusDomino server is running. 
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► Create the PUBSERV database. 


Only databases that contain the project and comment data for WebSphere 
Business Compass can be migrated. The scripts that are provided will not 
migrate access right data (WBICOLWIPUser.nsf and WBICOLReleasellser.nsf). 

Perform the following steps: 

1 . Edit the migration-run.bat or the migration-run. sh file in the 
publishing_server_instal l_root\ scri pts .wbps\mi grati on\domi no folder. In 
the file, set the following values: 

- DOMINO_HOST=: The fully qualified host name, short host name, or IP 
address of the Lotus Domino server. For example: 

D0MIN0_H0ST=domi noserver.myco.com 

- DOMINO_PORT=: The Domino server port. 

- DOMINO_USER=: The user ID of the Domino server administrator. 

- DOMINO_PASSWORD=: The password for the Domino server 
administrator. 

- DB_URL=jdbc:db2://[host]:[port]/pubserv: The URL of the DB2 server. 
The [host] is the fully qualified DNS (for example, 

dominoserver.myco.com), short DNS, or IP address of the DB2 server and 
[port] is the port used by the server. 

- DB_USER=: The user ID of the DB2 administrator. 

- DB_PASSWORD=: The password for the DB2 administrator. 

- SPACE_ID=: The ID for the Process Editor Space in the Spaces table in 
the database. 

For Windows®: 

- JAVA_EXEC=[java home pathj\bin\java.exe. 

For Linux®: 

- JAVA_EXEC=/user/lib/java/jre/bin/java: The path to a Java Virtual Machine 
(JVM), Version 1.5.0_06 or higher. You can download JVM into a Java 
Runtime Environment (JRE) by going to the following address: 
http://java.sun.com/javase/downloads/index.jsp 

When you have finished editing the file, save it. 

2. Run the migration tool: 

a. Open a command prompt. 

b. Change directories to the folder containing the saved file. 
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c. Enter the following command: 

• For Windows, usemigration-run.bat. 

• For Linux, use . /migration-run. sh. 

When the tool finishes, it displays the results of the migration. You can also 
view the log files for the migration in the folder in which you ran the migration 
tool. If you ran the tool from its folder, the log files are in the 
publishing_server_instal l_root\ scri pts .wbps\mi grati on\domi no folder: 

- wps-migration-user.log contains the messages displayed in the 
command window when the migration tool was running. 

- wps-migration-details.log contains the same information that is in the 
wps-migration-user.log plus additional information. 


Note: If the migration tool encounters a problem with a project element, 
it abandons migrating that project and starts migrating the next project. 
The migration tool does not migrate any part of the project. If you think 
that a single element might be causing the problem, launch WebSphere 
Business Modeler Publishing Server Version 6.0.2 and use the Draft or 
Release administration to delete the element. You can then rerun the 
migration tool. If the element you deleted was the only element causing 
the problem, the migration tool can now migrate the project. 


3. Uninstall WebSphere Business Modeler Publishing Server. For more 
information about uninstalling the product, see the IBM WebSphere Business 
Modeler Publishing Server Installation Guide Version 6.0.2 Installation Guide, 
which you can access by going to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6rxmx/topi c/com. i 
bm. btool s . hel p .model er . col 1 ab . publ i sh . doc/doc/ref erence/publ i shi ng_i 
nstall .pdf 

4. Uninstall WebSphere Portal (optional). 

5. Uninstall WebSphere Application Server (optional). 

6. Launch WebSphere Business Compass in a Web browser and verify that the 
data was migrated. 


2.2.4 WebSphere Integration Developer 

When you want to use the new features of the products, and delete the 
deprecated features, you use source artifacts migration using WebSphere 
Integration Developer. 
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Migrating source artifacts requires knowledge of new features available in 
WebSphere Dynamic Process Edition V7.0. If choosing artifact migration, there is 
no Version 6.0.2 specific migration required. The migration of a previous version 
of WebSphere Integration Developer is documented at the following address: 
http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.wbit.hel p. mi gr. doc/topi cs/tmwid.html 

If you are planning to have mixed levels of WebSphere BPM products, you will 
need to use relevant versions of WebSphere Integration Developer for future 
changes to the applications. If you use the required plug-ins, you could use the 
lower version of WebSphere Integration Developer, but you will not be able to use 
the enhancements available in the newer versions 

Special considerations for version to version migration can be found at the 
following address: 

http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.wbit.hel p. mi gr. doc/topi cs/cwi dcon.html 

When migrating from a previous version of WebSphere Integration Developer to 
Version 7.0, most of the migration is done automatically. However, there are a 
number of considerations to be aware of that might require additional manual 
configuration. The considerations given in the following sections are intended to 
assist in the version-to-version migration process. 

Validations 

With each new release of WebSphere Integration Developer, validators for 
various components, such as business objects, human tasks, and XSLT maps, 
are improved. After importing the artifacts to a newer version of WebSphere 
Integration Developer, there might be validation errors that the previous validator 
did not catch. 

Java validation 

When using the Service Data Objects (SDO) API to create a data object, there is 
an additional Java validation in WebSphere Integration Developer. 

SDO programming tips 

From WebSphere Integration Developer V6.0.X to WebSphere Integration 
Developer V6.1 , there are package name changes for a few classes, such as 
BOXMLSerializer, that can cause compilation errors. It is a best practice not to 
reference those classes directly, but to use Service Manager to locate the 
service. 
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Circular dependencies 

A newer version of WebSphere Integration Developer might detect circular 
dependencies of the modules or projects as errors, while an older version of 
WebSphere Integration Developer does not. 

To quickly resolve this issue, you can change the compiler option in your 
workspace references. Select Windows -» Preference Java ->• Compiler -> 
Building. Under the build path problems section, select the Warning option for 
Circular dependencies. Depending on the version of WebSphere Integration 
Developer that you are using, you might need to go to the Java perspective and 
open the preference window to see the Java option in the preferences list. 

The applications with circular dependencies might be running without a problem 
in the new environment. Although there are no current issues, it is necessary to 
check the project dependencies again. To avoid future issues, circular 
dependencies must be detected and removed. Use refactoring if you need to 
change the name of a component or its target namespace because they are 
invalid, and use the refactoring capabilities instead of simply changing the name 
or namespace in one place. If you do not use refactoring, you might encounter 
problems, as the name or target namespace of a component might be referenced 
by other artifacts. Refactoring those values would preserve the relationships. 

For example, a namespace must be an absolute Uniform Resource Identifier, for 
example, starting with http://. You should refactor the target namespace by 
pressing Alt+Shift+R on the target namespace field of the Properties page. 

XPath 

XPath can be used in mediation flows and business processes. Prior to 
WebSphere Integration Developer V6.1 , a distinction was not made between 
business object attributes defined as xsd:element and those defined as 
xsd:attribute. If XPATH is used, you might see the following message in the 
problems view after migrating: 

The <attribute_name> schema element was not found in the 
<xpath_expression> XPATH. 

To fix this error, put an symbol in front of the attribute name, or reselect the 
XPATH in the XPATH Expression Builder. 

For example, there is a business object called MyBO that has an attribute 
“myAttribute” defined as xsd:attribute. 

The XPATH expression created in Version 6.0x is: 

/MyBO/myAttribute 
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Change it to: 

/MyBO/@myAttri bute 

Component-specific considerations 

This section provides information specific to components. 

Business object map 

For WebSphere Integration Developer V6.1 .2 or after, if you have mappings that 
include an inherited type, you might receive the following warning message: 
CWLAT0064W: The 4 transform includes an inherited type, which might 
produce unwanted side effects when the map runs. 

Business object maps can work on generalizations of types. This warning is 
raised to indicate that the transform will still execute even if the inherited type 
comes in as part of the instance document. This becomes more of a concern 
when mapping elements are involved in a substitution group. Typically, if the 
element is not involved in a substitution group, you do not need to be concerned 
about the warning. 

XSLT mapper 

There was a major change in XSLT mapper for WebSphere Integration 
Developer V6.1 . 

You can easily identify whether maps are created prior to Version 6.1 using the 
file extension. The file extension of the old Version 6.0.x XSLT map files is .xmx, 
and the one for the new ones is .map. 

If XSLT map files are created using Version 6.0.x, they continue to work in 
Version 6.1 or after. Therefore, WebSphere Integration Developer does not 
migrate those files automatically, and migration is not mandatory, but the maps 
need to be migrated for further enhancement. 

In addition, it is highly recommended to migrate the old .xmx files to benefit from 
the performance improvement in the new XSLT map architecture. 

To migrate the XSLT maps, double-click the file, which will open the mapping 
migrator editor, and perform the following steps: 

1 . (Optional) Click the Find All Old Mappings button to find other old mappings 
in the workspace. 

2. Select and deselect primitives to migrate in the table. 

3. (Optional) Select the Utilize existing XSL file for custom mappings option. 
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4. (Optional) Deselect the Backup existing xmx and associated xsl files 
option. 

5. Press the Migrate button. 

To optimize the process, note the following items: 

► This mapping migrator discovers all the old map files (.xmx files) in the 
workspace. You can select to migrate them all at once. 

► Before launching the migrator, disable the automatic build. During the 
migration, there are many file changes that kick off auto-build frequently. 
Disabling it will shorten the migration time. After the mapping migration is 
completed, enable the auto-build again. 

2.2.5 WebSphere Process Server 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), information about migration to Version 7.0 is available at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wps. doc/doc/we 1 come_wps_mig.html 

Special consideration for WebSphere Process Server for z/OS 

We discuss considerations for z/OS in Chapter 7, “Migrating WebSphere Process 
Server V6.1 .2 to V7.0 on a z/OS system” on page 341 . Additional information 
about version to version migration for z/OS is available at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere . wps . z . doc/doc/wel come_bpm_mi g . html 


2.2.6 WebSphere Enterprise Service Bus 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration is available at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wesb. doc/doc/wel come_wps_mig.html 

If the source version is Version 6.0.2, the profile has to be created using the 
profile management tool (PMT) and not the migration command 
BPMCreateTargetProfile. 
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Migration information for WebSphere Enterprise Service Bus on z/OS is available 
at the following addresses: 

► http : //publ i b . boul der . i bm . com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com . i 
bm. websphere. wesb.zseries. doc/doc/ cmig_vtv_bpmmig_ovw.html 

► http : //publ i b . boul der. i bm . com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com . i 
bm. websphere. wesb. zseries. doc/doc/we 1 come_wps_mig.html 


2.2.7 WebSphere Business Service Fabric 

WebSphere Business Service Fabric-specific profiles (and PMT support) was 
introduced in Version 6.2. Prior to that version, WebSphere Business Service 
Fabric applications were installed on WebSphere Process Server-only profiles. 
For that reason, the standard V2V migration tooling support for WebSphere 
Business Service Fabric, introduced in Version 7.0, is supported (and tested) 
only for Version 6.2 to Version 7.0. 

For versions prior to Version 6.2, if WebSphere Business Service Fabric is part of 
the stack being migrated, you can still achieve migration using the V2V migration 
tooling, with the use of some workarounds as follows. The migration tooling 
provides automatic procedure to help migrate fabric applications. 

Migrating the IBM WebSphere Business Services Fabric involves migrating the 
Foundation Pack and Tool Pack, configuring security, and updating WebSphere 
Business Service Fabric applications to use the new functions. 

For WebSphere Business Services Tool Pack, perform the following steps: 

1 . Migrate the Composition Studio project. 

2. Migrate the WebSphere Business Service Fabric in a unit test environment 
(UTE). 

For WebSphere Business Services Foundation Pack, migrate the WebSphere 
Business Service Fabric application from Version 6.0.2 to 6.1 . 

Information regarding WebSphere Business Service Fabric migration from 
Version 6.0.2 release is available in the Information Center at the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. ws. f abric. mi gr. doc/mi gr602/concept/c_i ntrowbsf.html 
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The general steps involved in migration are: 

1 . Export the WebSphere Business Service Fabric FCA (ontology content) 
archive and dependency archives for your current release projects that you 
need to migrate using the WebSphere Business Service Fabric administrative 
console. 

2. Install the Version 7.0 stack, including WebSphere Business Service Fabric, 
with no profiles. 

3. Migrate from releases prior to Version 6.2 using the standard V2V tool. This 
will migrate the WebSphere Business Service Fabric applications on that 
WebSphere Process Server profile, because the WebSphere Business 
Service Fabric migration script would be executed. 

4. Augment the existing profiles from DMGR and managed nodes with 
WebSphere Business Service Fabric DMGR and managed nodes using 
WebSphere Business Service Fabric profiles. This action is required to use 
the Profile branding capability introduced in Version 7.0 (like displaying 
WebSphere Business Service Fabric in the servers list in the administrative 
console). 

5. Import the data exported from Step 1 into WebSphere Business Service 
Fabric V7.0 using the WebSphere Business Service Fabric administrative 
console. 

6. Drop the current WebSphere Business Service Fabric database, as it is no 
longer used in Version 7.0. All WebSphere Business Service Fabric 
repository data, is stored in WebSphere Process Server common database 
(WPSCRDB). 

2.2.8 WebSphere Business Monitor 

The procedures for migrating from Version 6.0.2 of WebSphere Business Monitor 
to Version 7.0 can be found in the Information Center found at the following 
address: 

http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_602 . html 

Migrating from WebSphere Business Monitor V6.0.2 to V7.0 involves two main 
tasks: migrating models and migrating data. 

► Model migration involves converting and deploying models. 
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► Data migration involves using the WebSphere Business Monitor V7.0 
Migration Wizard (referred to in the documentation as the migration utility). 


Important: 

If you are using WebSphere Business Monitor V6.0.1, you must first 
migrate to Version 6.0.2 before migrating to Version 7.0. 

If you are using WebSphere Business Monitor V6.0.2.1 , you must install 
Interim Fix 5 for WebSphere Business Monitor V6. 0.2.1 before beginning 
the migration process. 


The Version 7.0 Monitor Model editor automatically converts WebSphere 
Business Monitor V6.0.2 models. After a model is converted to the Version 7.0 
format, you can deploy it using the WebSphere Business Monitor V7.0 
administrative console. 

You can migrate Version 6.0.2 monitor models to the Version 7.0 format either in 
the Monitor Model editor or by using a batch file that does not require an Eclipse 
environment. Monitor models in Version 6.1 format are already compatible with 
Version 7.0. 

Migration task list 

Migration from WebSphere Business Monitor V6.0.2 to V7.0 occurs in the 
following order: 

1 . Migrating the Adaptive Action Manager data 

Migrate the Adaptive Action Manager data. Using the migration utility to 
perform this task, the Adaptive Action Manager data migration migrates all the 
action services’ configuration and uncompleted alerts. 

2. Migrating Version 6.0.2 models 

Migrate your WebSphere Business Monitor V6.0.2 monitor models. Migrate 
monitor models using the Monitor Model editor (a component of the 
WebSphere Business Monitor V7.0 development toolkit) and the WebSphere 
Business Monitor V7.0 administrative console. 

3. Migrating context instance data 

Migrate all of the completed context instances, model by model. You use the 
migration utility to perform this task, and migrating context instance data 
involves exporting all of the completed instances for the selected models from 
the Version 6.0.2 data mart database, converting the instances into the 
Version 7.0 format, and importing them into the Version 7.0 database. 
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4. Migrating data for models with “partially exported” status 

When all WebSphere Business Monitor V6.0.2 monitoring context instances 
have completed, you can use the migration utility to complete the data 
migration for models with “partially exported” status. 

5. Migrating action services data again 

Migrate action services’ data again to capture any new alerts. 

In Version 6.0.2, WebSphere Business Monitor used cross-cell, which was the 
only way to configure communication. In Version 7.0, you can use queue bypass. 
Migration will use the strategy used in the current release, which is a 
queue-based approach. If you want to configure queue bypass, you need to 
configure it after migration. The information about configuring queue bypass is 
available at the following address: 

http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.btool s.hel p. monitor. inst.doc/i nst/cf g_qb.html 


2.2.9 Migrating WebSphere Business Modeler and WebSphere 
Business Compass data 

After migrating the WebSphere Business Modeler projects, follow the procedure 
documented for data migration for WebSphere Business Modeler and 
WebSphere Business Compass, which can be found at the following address: 
http : // publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.btool s . hel p .model er . col 1 ab. publ i sh .mi g . doc/mi g/mi grate_602 . html 


2.3 Special considerations for migration from Version 
6.1 


This section contain migration information specific to migrating from Version 6.1 
to Version 7.0 of WebSphere Dynamic Process Edition Server. 


2.3.1 Business Space powered by WebSphere 

Business Space was not available in Version 6.1 . For a new Version 7.0 
installation, you can find the Business Space configuration procedure outlined in 
the Information Center at the following address: 

http: //publ ib.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. websphere. wbpm. bspace. confi g .doc/doc/tcon_conf i g_bspace.html 
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For information about configuring Business Space on WebSphere Portal server, 
go to the following address: 

http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m. websphere. wbpm.bspace.config.doc/doc/tcfg_bsp_portal .html 


2.3.2 WebSphere Business Modeler 

The procedure to migrate from Version 6.1 is the same as that for migrating from 
Version 6.0.2 to WebSphere Dynamic Process Server Edition V7.0 (see 2.2.2, 
“WebSphere Business Modeler” on page 49). 

There are no special considerations for migrating from Version 6.1 of the 
WebSphere Business Modeler. The migration information is available at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. btool s .model er. advanced . i nst . doc/mi grati ng/mi grateprojects . html 


2.3.3 WebSphere Business Compass 

Version 6.1 of the product was called WebSphere Modeler Publishing Server. 
The procedure for migration to Version 7.0 of the product is outlined at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. btool s.hel p. modeler. col 1 ab.publ ish. mi g. doc/mi g/mi grate_db26-l-l.html 


2.3.4 WebSphere Integration Developer 

Migrating from Version 6.1 to Version 7.0 of WebSphere Integration Developer is 
a straight forward procedure that is documented at the following address: 
http://publib.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m.wbit.hel p. mi gr. doc/topi cs/tmwid. html 

Special considerations for version to version migration are documented in the 
Information Center at the following address: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wbit.hel p. mi gr. doc/topi cs/cwi dcon.html 
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2.3.5 WebSphere Process Server 


For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration to Version 7.0 is available at the following 
address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps. doc/doc/we 1 come_wps_mig.html 

Special consideration for WebSphere Process Server for z/OS 

We have discuss considerations for z/OS in Chapter 7, “Migrating WebSphere 
Process Server V6.1 .2 to V7.0 on a z/OS system” on page 341 . Additional 
information about version to version migration for z/OS is available at the 
following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere .wps . z . doc/doc/wel come_bpm_mi g . html 


2.3.6 WebSphere Enterprise Service Bus 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration is available at the following address: 
http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wesb. doc/doc/wel come_wps_mig.html 


2.3.7 WebSphere Business Service Fabric 


Note: To migrate from Version 6.1 , you need to migrate to Version 6.1 .2 and 
then to Version 6.2 before migrating to Version 7.0. 


The information about migrating from Version 6.1 to Version 6.1.2 is documented 
at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. ws . fabri c .mi gr .doc/mi gr612/concept/c_i ntrowbsf612 . html 

Migrating the WebSphere Business Services Fabric application involves 
migrating the Foundation Pack, Tool Pack, configuring security, and the 
WebSphere Business Services Fabric application to use the functionality of 
Version 6.1 .2. 
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Moving from one version of WebSphere Business Services Fabric to a newer 
release or a higher release level of WebSphere Business Services Fabric is 
referred to as version-to-version migration. Version-to-version migration occurs 
when you install a new version of a product, such as WebSphere Business 
Services Fabric and then copy relevant application and configuration data from 
the old installation to the new installation. 

Pre-migration considerations 

It is important to follow the procedure detailed below before you begin the 
process of migrating to WebSphere Business Services Fabric V6.1 .2: 

► For Foundation Packs 

- Back up the WebSphere Business Services Fabric database using 
database utilities. 

- Back up the WebSphere Process Server profile where WebSphere 
Business Services Fabric is installed using the application server backup 
utilities, such as backup config. 

► For Tool Packs 

- Back up the Derby database by copying it to a different location. 


Note: Before you migrate WebSphere Business Services Fabric from 
Version 6.1 to Version 6.1 .2, you need to first install and configure 
WebSphere Process Server V6.1.2 and WebSphere Integration 
Developer V6. 1.2. 


2.3.8 WebSphere Business Monitor 

The information about migrating from WebSphere Business Monitor V6.1 and 
V6.1 .2 is the same. This information is documented at the following address: 
http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_61 . html 

Migrating from WebSphere Business Monitor V6.1 .x to V7.0 requires you to 
migrate your existing profiles, upgrade the database, deploy the Monitor 
scheduled services, migrate the Alphablox® repository, update configurations, 
and migrate the dashboards. 

General sequence of events 

The migration path for each environment that includes WebSphere Business 
Monitor will be unique, but the three common areas of migration include 
applications, data, and profiles. 
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Note: Starting with WebSphere Business Monitor V7.0, the Alphablox 
repository is in the WebSphere Business Monitor database by default. 
Regardless of the previous WebSphere Business Monitor version 
implemented, you must migrate the existing Alphablox repository to the 
WebSphere Business Monitor V7.0 database repository. During migration, the 
existing database repository contents is moved to the MONITOR 
schema-based repository. 


The general sequence of events for migrating from Version 6.1 .x to Version 7.0 is 
similar to the following list: 

1 . Back up existing profiles, the database, and the Alphablox repository. 

2. Perform the prerequisite tasks for portlet-based dashboards. 

3. Install the prerequisite software. 

4. Install WebSphere Business Monitor V7.0 on the same machine as the 
existing version from which you are migrating. 

5. Migrate existing profiles to the new version. 

6. Upgrade the Version 6.1 .x or Version 6.2.x database to the Version 7.0 
schema using a utility or the .ddl file directly. 

7. Deploy the WebSphere Business Monitor scheduled services. 

8. Migrate the Alphablox repository. 

9. Update the WebSphere Business Monitor configuration. 

10. Migrate the dashboards. 

Database migration 

Database migration should take place after stand-alone profile migration or 
deployment manager profile migration (but before migrating managed nodes). 
You can migrate (upgrade) the WebSphere Business Monitor database by using 
Data Definition Language (DDL) files or by using the database upgrade utility. To 
manually upgrade the database and for some other situations listed below, you 
can use the DDL files that are provided. 

Deploying the WebSphere Business Monitor scheduled 
services 

The deploying WebSphere Business Monitor scheduled services task takes 
place after profile migration and database migration. In a stand-alone installation, 
the WebSphere Business Monitor scheduled services will be deployed during 
migration. In a network deployment environment (ND), model migration requires 
that you deploy the WebSphere Business Monitor scheduled services manually. 
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Deploying the WebSphere Business Monitor scheduled services creates the 
WebSphere Application Server scheduler resource that calls the Data Memory 
System (DMS) and KPI history and prediction for each model. 

Alphablox migration 

Migrating a WebSphere Business Monitor V6.1 .x or V6.2.X installation with 
Alphablox to a WebSphere Business Monitor V7.0 installation involves the 
creation of the WebSphere Business Monitor - Alphablox repository database 
tables, the installation of Alphablox and configuration of server properties, and 
the transfer of the old repository contents to the MONITOR schema-based 
repository. The Alphablox repository database tables are created during the 
database migration. The installation of Alphablox and the configuration of server 
properties are done during WebSphere Business Monitor V7.0 installation and 
profile migration. So here, only the Alphablox repository is migrated. When the 
Alphablox repository of the Version 6.1 or Version 6.2 profile is in the same 
WebSphere Business Monitor database using the same WebSphere Business 
Monitor schema, the Alphablox migration happens by default and no manual 
steps are required. 

Updating the WebSphere Business Monitor configuration 

Updating the WebSphere Business Monitor configuration takes place after profile 
migration, database migration, WebSphere Business Monitor scheduled services 
deployment, and Alphablox repository migration. You can complete this task by 
running the monConfigurationUpgrade script. Updating the WebSphere Business 
Monitor configuration is a required task, regardless of whether Alphablox is 
installed. 

Migrating the dashboards 

To maintain your dashboard configurations from a previous release, you must 
migrate the dashboards. This step takes place after finishing the profile 
migration, database migration, and Alphablox repository migration. 


2.4 Special consideration for migration from Version 

6.1.2 


This section contains migration information specific to migrating from a Version 
6.1.2 release to Version 7.0 of WebSphere Dynamic Process Edition Server. 
Each section contains specific information pertaining to a Business Process 
Management product for a Version 6.1.2 to Version 7.0 migration. 
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Business Space and WebSphere Business Monitor have different requirements 
that depend on what servers need to be running during migration, which then 
depends on your topology. In Chapter 6, “Migrating BPM V6.1 .2 to WebSphere 
Dynamic Process Edition V7.0” on page 195, we describe the sequence for a 
high availability cluster topology. 

2.4.1 Business Space powered by WebSphere 

Business Space is first available in Version 6.1.2. Migration involves to Version 
7.0 involves the following actions: 

► Migrate the Business Space database schema. Information about this task 
can be found at the following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm .websphere . wps . doc/doc/tmi g_vtv_upg_bsdb . html 

► Migrate the Business Space database data. Information about this task can 
be found at the following address: 

http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm. websphere .wps . doc/doc/tmi g_vtv_upg_bspacedb_mi g . html 

► Migrate dashboards: 

Information about each type of dashboard can be found at the following 
addresses: 

- Web dashboards: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/ 
com . i bm . btool s . hel p .moni tor .mi g . doc/mi g/mi g_dash_bspace . html 

- Portal based dashboard: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/ 
com . i bm . btool s . hel p .moni tor .mi g . doc/mi g/mi g_dash_portal . html 


2.4.2 WebSphere Business Modeler 

The procedure to migrate from Version 6.1 .2 is the same as that for migrating 
from Version 6.0.2 to WebSphere Dynamic Process Server Edition V7.0 (see 
2.2.2, “WebSphere Business Modeler” on page 49). 

There are no special considerations for migrating from Version 6.1 .2 of the 
WebSphere Business Modeler. The migration information is available at the 
following address: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s .model er .advanced . i nst . doc/mi grati ng/mi grateprojects . html 
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2.4.3 WebSphere Business Compass 


If you are using Version 6.1.2 of the BPM products, the WebSphere Business 
Compass migration is divided into four different categories: 

► Migrating WebSphere Business Compass (WebSphere Business Modeler 
Publishing Server) only. Information about this task can be found at the 
following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col lab. publ ish. mi g. doc/mi g/migrate_standalo 
ne.html 

► Migrating when WebSphere Business Compass is running the same profile 
as WebSphere Business Monitor or WebSphere Process Server. Information 
about this task can be found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col lab. publ ish. mi g. doc/mi g/migrate_with_wps 
_or_mon . html 

► Migrating when WebSphere Business Modeler Publishing Server is running in 
a high availability environment without WebSphere Business Monitor or 
WebSphere Process Server. Information about this task can be found at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
.ibm.btool s.hel p. modeler. col 1 ab. publ ish. mi g. doc/mi g/migrate_standalo 
ne_clus.html 

► Migrating when WebSphere Business Compass is running in a high 
availability environment with WebSphere Business Monitor or WebSphere 
Process Server. Information about this task can be found at the following 
address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col 1 ab. publ ish. mi g. doc/mi g/migrate_clus_wit 
h_wps_or_mon . html 


2.4.4 WebSphere Integration Developer 

Migrating from Version 6.1 .2 to Version 7.0 of WebSphere Integration Developer 
is a straight forward procedure that is documented at the following address: 
http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. wbit. he! p. mi gr. doc/topi cs/tmwid. html 
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Special considerations for version to version migration is documented in the 
Information Center at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m.wbit.hel p. mi gr. doc/topi cs/cwi dcon.html 


2.4.5 WebSphere Process Server 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration to Version 7.0 is available at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wps.doc/doc/wel come_wps_mig.html 

Special consideration for WebSphere Process Server for z/OS 

We have discuss considerations for z/OS in Chapter 7, “Migrating WebSphere 
Process Server V6.1 .2 to V7.0 on a z/OS system” on page 341 . Additional 
information about version to version migration for z/OS is available at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere . wps . z . doc/doc/wel come_bpm_mi g . html 


2.4.6 WebSphere Enterprise Service Bus 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration is available at the following address: 
http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wesb. doc/doc/wel come_wps_mig.html 


2.4.7 WebSphere Business Service Fabric 


Note: To migrate from Version 6.1 .2, you need to migrate to Version 6.2 before 
migrating to Version 7.0. 


Information about migrating from Version 6.1 .2 to Version 6.2 is documented at 
the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. ws. f abri c. mi gr. doc/mi gr620/concept/c_i ntrowbsf620.html 
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This section has information about how to migrate the WebSphere Business 
Services Fabric V6.1 .2 environment to V6.2. 

Migrating is the process of moving from one version of WebSphere Business 
Services Fabric to another while minimizing changes to configurations and user 
applications. This allows the existing application and configuration data to be 
used in the next version. 

With WebSphere Business Services Fabric migration, the new WebSphere 
Business Services Fabric version is installed alongside the older WebSphere 
Business Services Fabric version. The data in the form of Fabric Content 
Archives (FCAs) is copied from the old version to the new version. Migrating is 
different from updating, where out-of-date files or data in an existing installation 
are replaced with current information. Refresh packs, interim fixes, and fix packs 
are examples of updates. 

WebSphere Business Services Fabric supports only data migration and does not 
support profile migration in Version 6.2. If you are migrating a WebSphere 
Process Server profile (containing WebSphere Business Services Fabric) from 
Version 6.1 .2 to Version 6.2, uninstall the WebSphere Business Services Fabric 
configuration and applications from the WebSphere Process Server profile. 
Migrate the WebSphere Process Server profile to Version 6.2 and augment the 
profile with WebSphere Business Services Fabric. 

To migrate WebSphere Business Services Fabric from Version 6.1 .2 to Version 
6.2, complete the following high level steps: 

1 . Commit all the WebSphere Business Services Fabric data (applications and 
projects created in WebSphere Business Services Fabric) to the repository. 

2. Export all the data as Fabric Content Archives (FCA) from WebSphere 
Business Services Fabric V6.1 .2. 

3. Uninstall the WebSphere Business Services Fabric configuration and 
applications from the Version 6.1.2 profile. 

4. Create a backup of the fabricdb database and drop the database. The 
database will be created as a part of the augmentation process. 

5. Migrate the WebSphere Process Server V6.1 .2 profile to WebSphere Process 
Server V6.2. 

6. Augment the WebSphere Process Server V6.2 profile to WebSphere 
Business Services Fabric V6.2. 

7. Import the data into WebSphere Business Services Fabric V6.2.0. 
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2.4.8 WebSphere Business Monitor 


Information about migrating from WebSphere Business Monitor V6.1 and V6.1 .2 
is the same. It is documented at the following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_61 . html 


2.5 Special consideration for migration from Version 6.2 

This section contains migration information specific to migrating from Version 6.2 
to Version 7.0 of WebSphere Dynamic Process Edition Server. Each section 
contains specific information pertaining to a Business Process Management 
product for a Version 6.2 to Version 7.0 migration. 

Business Space and WebSphere Business Monitor have different requirements 
that depend on what servers need to be running during migration, which then 
depends on your topology. In Chapter 6, “Migrating BPM V6.1 .2 to WebSphere 
Dynamic Process Edition V7.0” on page 195, we describe the sequence for a 
high availability cluster topology. 


2.5.1 Business Space powered by WebSphere 

Information about how to migrate Business Space widgets from Version 6.2 to 
Version 7.0 is available at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. bspace. hel p.devt. doc/doc/mi grating/mi grating62widgets.html 

You must migrate widgets developed for Version 6.2 of Business Space into 
widgets that run in Version 7.0 of Business Space. If you do not migrate these 
widgets, they will not work in Version 7.0. 

The migration documentation assumes that you have experience in developing 
iWidgets for Business Space V6.2. For information about developing iWidgets, 
see the Version 6.2 documentation found at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6r2mx/topi c/com. i bm. 
bspace. 620. hel p.devt. doc/doc/concepts/busi ness_space_devt/coverview.htm 
1 

To migrate Version 6.2 widgets, perform the following steps: 

1 . Migrate the profile containing the custom widgets. 

2. Uninstall the custom widget EAR. 


72 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 


3. If your Version 6.2 widgets use the IBM Dojo Toolkit, upgrade them to use 
Dojo VI .3.2. For information about how to upgrade to Dojo 1 .3.2, go to the 
following address: 

http://www.dojotool kit.org/ 

In Business Space V7.0, the instance of the IBM Dojo Toolkit is based on 
V3.2 of the Dojo Toolkit. However, this bundled version will be updated as 
needed over time. This could include entirely new Dojo versions, as well as 
specific defect fixes. The compatibility of future Dojo versions is defined by the 
Dojo project. 

4. If your widgets need to support multiple languages, update the iWidget XML 
by adding localized event descriptions. To add localized event descriptions, 
add one <iw:alt> element for each language. The <iw:alt> element is a new 
child of the <iw:Description> element: 

<iw:eventDescription 
title="{ title }" 
lang=" en " 

<iw:alt 

description="{ description }" 
title="{ title }" 
lang="{ languages }" /> 

</iw:eventDescription> 

5. Package the widgets. 

a. Create an EAR directory. Copy the EAR files containing the migrated 
widget definition files and widget implementation files. Copy the EAR files 
into an EAR directory. 

b. Create a catalog directory and copy the catalog XML (widget registration) 
files into it. 

c. Create an endpoints directory and copy the endpoint registration files into 
it if there are any endpoint registration files. 

d. Optional: Create a templates directory and copy template ZIP files into it if 
there are any template ZIP files. The template definitions in the ZIP files 
must be in the Lotus Mashups template format. 

e. Create a help directory and copy the help plug-ins into it if there are any 
help plug-ins. 
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f. Compress the ear, catalog, endpoints, templates, and help directories. 
Check that the structure of the compressed file contains the following 
items: 

• ear\widgets_name.ear (one or more EAR files) 

• catalog\catalog_name.xml 

• endpoints\*.xml 

• templates\*.zip 

• help\eclipse\plugins\* 

6. At a command prompt, change directories to the profilejroot / bi n directory. 

7. Enterwsadmin.bat -conntype NONE and then enter the appropriate command: 

- For migrating the widgets into a non-clustered environment, run 
$AdminTask instal lBusinessSpaceWidgets {-nodeName node 
-serverName server -widgets fullpath}. 

- For migrating the widgets into a clustered environment, run $AdminTask 
instal lBusinessSpaceWidgets {-clusterName cluster -widgets 
fullpath}. 

Fullpath is the name and location of the ZIP file or parent folder you created. 

8. Enter Exit. 

9. Restart the server or cluster. 

Changes to the widget and endpoint registration files 

The migration process automatically migrates the widget registration XML and 
endpoint registration XML files to the Version 7.0 format by making the changes 
listed in this topic. 


2.5.2 WebSphere Business Modeler 

The procedure to migrate from Version 6.2 is the same as that for migrating from 
Version 6.0.2 to WebSphere Dynamic Process Server Edition V7.0 (see 2.2.2, 
“WebSphere Business Modeler” on page 49). There are no special 
considerations for migrating from WebSphere Business Modeler V6.2. The 
migration information is available at the following address: 
http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s .model er. advanced . i nst . doc/mi grating/mi grateprojects . html 
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2.5.3 WebSphere Business Compass 


If you are using Version 6.2 of the BPM products, the WebSphere Business 
Compass migration is approached differently depending on the topology: 

► Migrating WebSphere Business Compass (WebSphere Business Modeler 
Publishing Server) only. Information about this task can be found at the 
following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col lab. publ ish. mi g. doc/mi g/migrate_standalo 
ne6202.html 

► Migrating when WebSphere Business Compass is running the same profile 
as WebSphere Business Monitor or WebSphere Process Server. Information 
about this task can be found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col lab. publ ish. mi g. doc/mi g/migrate_with_wps 
_or_mon6202.html 

► Migrating when WebSphere Business Modeler Publishing Server is running in 
a high availability environment without WebSphere Business Monitor or 
WebSphere Process Server. Information about this task can be found at the 
following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col 1 ab. publ ish. mi g. doc/mi g/migrate_standalo 
ne_clus6202.html 

► Migrating when WebSphere Business Compass is running in a high 
availability environment with WebSphere Business Monitor or WebSphere 
Process Server. Information about this task can be found at the following 
address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
.ibm.btool s.hel p. modeler. col 1 ab. publ ish. mi g. doc/mi g/migrate_clus_wit 
h_wps_or_mon-6202copy . html 


2.5.4 WebSphere Integration Developer 

Migrating from Version 6.2 to Version 7.0 of WebSphere Integration Developer is 
a straight forward procedure that is documented at the following address: 
http: //publ ib.boul der. i bm. com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. wbit. he! p. mi gr. doc/topi cs/tmwid. html 
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Special considerations for version to version migration is documented in the 
Information Center at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m.wbit.hel p. mi gr. doc/topi cs/cwi dcon.html 


2.5.5 WebSphere Process Server 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration to Version 7.0 is available at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wps.doc/doc/wel come_wps_mig.html 

Special consideration for WebSphere Process Server for z/OS 

We discuss considerations for z/OS in Chapter 7, “Migrating WebSphere Process 
Server V6.1 .2 to V7.0 on a z/OS system” on page 341 . Additional information 
about version to version migration for z/OS is available at the following address: 
http://publib.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. websphere . wps . z . doc/doc/wel come_bpm_mi g . html 


2.5.6 WebSphere Enterprise Service Bus 

For all earlier releases (Version 6.0.2, Version 6.1, Version 6.1.2, and Version 
6.2), the information about migration is available at the following address: 
http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wesb. doc/doc/wel come_wps_mig.html 


2.5.7 WebSphere Business Service Fabric 

Information about how to migrate from WebSphere Business Server Fabric V6.2 
to Version 7.0 is available at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. ws. fabric. mi gr. doc/mi gr70/concept/c_i ntrompandzos.html 

Migration consideration for z/OS 

Information about migration considerations for z/OS can be found at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. ws. fabric. mi gr. doc/mi gr70/concept/c_i ntrompandzos.html 
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2.5.8 WebSphere Business Monitor 


Information about how to migrate from WebSphere Business Monitor V6.2 to 
WebSphere Business Monitor V7.0 is available at the following address: 
http : //publ i b.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_62_ov . html 

Migrating from WebSphere Business Monitor V6.2.X to Version 7.0 requires that 
you migrate your existing profiles, upgrade the database, migrate the Alphablox 
repository, and migrate the dashboards. 


2.5.9 General sequence of events 

The migration path for each environment that includes WebSphere Business 
Monitor will be unique, but the three common areas of migration include 
applications, data, and profiles. 


Note: Starting with WebSphere Business Monitor V7.0, the Alphablox 
repository is in the WebSphere Business Monitor database by default. 
Regardless of the previous WebSphere Business Monitor version 
implemented, you must migrate the existing Alphablox repository to the 
WebSphere Business Monitor V7.0 database repository. During migration, the 
existing database repository contents is moved to the MONITOR 
schema-based repository. 


The general sequence of events for migrating from Version 6.2.x to Version 7.0 is 
similar to the following list: 

1 . Back up existing profiles, the database, and the Alphablox repository. 

2. Perform prerequisite tasks for portlet-based dashboards. 

3. Install the prerequisite software. 

4. Install WebSphere Business Monitor V7.0 on the same machine that the 
existing version you are migrating from is installed. 

5. Migrate existing profiles to the new version. 

6. Upgrade the Version 6.1 .x or Version 6.2.x database to the Version 7.0 
schema using a utility or the .ddl file directly. 

7. Migrate the Alphablox repository. 

8. Migrate the dashboards. 
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Preparing for migration 

Before getting started with your WebSphere Business Monitor migration, there 
are several tasks that you should complete. The following tasks should serve as 
your pre-migration checklist. 

Profile migration overview 

Profile migration involves profile creation and the migration of configurations and 
applications. Before you can begin profile migration, you should have completed 
the remaining tasks in this section that are relevant to your system environment. 

Database migration overview 

Database migration should take place after stand-alone profile migration or 
deployment manager profile migration. You can migrate (upgrade) the 
WebSphere Business Monitor database by using Data Definition Language 
(DDL) files or by using the database upgrade utility. To manually upgrade the 
database and for some other situations listed below, you can use the DDL files 
that are provided. 

Alphablox migration overview 

Migrating a WebSphere Business Monitor Version 6.1 .x or Version 6.2.x 
installation with Alphablox to a WebSphere Business Monitor V7.0 installation, 
involves the creation of the WebSphere Business Monitor - Alphablox repository 
database tables, the installation of Alphablox and configuration of server 
properties, and the transfer of the old repository contents to the MONITOR 
schema-based repository. The Alphablox repository database tables are created 
during the database migration. The installation of Alphablox and configuration of 
server properties are done during WebSphere Business Monitor V7.0 installation 
and profile migration. So here, only the Alphablox repository is migrated. When 
the Alphablox repository of the Version 6.1 or Version 6.2 profile is in the same 
WebSphere Business Monitor database using the same WebSphere Business 
Monitor schema, the Alphablox migration happens by default and no manual 
steps are required. 

Migrating the dashboards 

To maintain your dashboard configurations from a previous release, you must 
migrate the dashboards. This step takes place after finishing the profile 
migration, database migration, and Alphablox repository migration. 
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2.6 Known limitations 


If the customer chooses to migrate only part of the stack, then the profile 
migration steps will have to be done manually. 

If WebSphere Process Server and WebSphere Business Monitor are kept in 
different release levels, there will be a need to keep the tool kit for both the levels 
to make any modifications later. In this scenario, use separate cells for 
WebSphere Business Monitor and WebSphere Process Server. The 
communication strategy to be used will be a cross-cell configuration. This will be 
true if your use a queue-based approach or queue-bypass approach 
(recommended). 

2.6.1 Known limitations for WebSphere Process Server 

The following article in the Information Center lists known compatibility issues 
when migrating to WebSphere Process Server V7.0: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com.ib 
m. websphere. wps.doc/doc/cmi g_vtv_compat.html 


2.6.2 Known limitations for WebSphere Business Fabric 

WebSphere Business Fabric supports version to version migration from Version 
6.2 onwards. Please contact IBM software support if your WebSphere Business 
Fabric version is either Version 6.0.2, Version 6.1 , or Version 6.1 .2. WebSphere 
Business Fabric does not support a non-root installation. 

2.6.3 Known limitations for WebSphere Adapters 

All WebSphere Adapters for V6.0.2 and WebSphere Adapter for SAP V6.0.2, 
V6.1 .0, V6.1 .2, and V6.2.0 are not supported on WebSphere Process Server 
V7.0. This set of adapters has to be updated to Version 7.0 before any 
applications using them can be deployed on WebSphere Process Server V7.0. 
This means that you cannot use runtime migration for modules with these 
adapters. 

This has special implications for long running processes that have imports or 
exports that use one of these adapters. The preferred method for migrating long 
running processes is the runtime migration, because the data associated with the 
long running process is carried to the target environment. 
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We expect this issue to be resolved in a future Fix Pack when the runtime 
migration will be updated to support the migration of these adapters and their 
related configuration. If this fix is not available when you perform your migration, 
you can use one of the following approaches: 

► Option 1 : If you plan to use runtime migration, perform the following steps: 

a. In source version, split the adapter with its export or import into a separate 
business integration module. 

b. During migration, uninstall this application from the source environment. 

c. Perform the runtime migration. 

d. After the runtime migration, use WebSphere Integration Developer V7.0 to 
update the module to Version 7.0. 

e. Install the application on the target environment. 

► Option 2: Use the manual or artifact migration methods. 

These methods use parallel production environments, allowing you to drain 
the old process instances from the pre-migration environment, and start new 
instances on the target environment with the migrated application. 


2.7 Troubleshooting 

Information about troubleshooting migration errors can be found in the 
Information Center at the following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps.doc/doc/tmi g_vtv_bpmtroublesht.html 

This article has information about the following errors: 

► Application installation error. 

► Application server error. 

► Business Rules manager is not automatically migrated. 

► Communication with deployment manager error. 

► Connector Exception. 

► Database connectivity exceptions. 

► Out of memory error. 

► Profile creation error. 

► Servlet error. 

► Synchronization error. 

► WebSphere Process Server client migrations 

► WSDL validation exception. 
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3 


Runtime migration 


This chapter addresses general considerations when migrating a Business 
Process Management (BPM) runtime to BPM Version 7.0. In this chapter, we 
discuss the runtime migration of the WebSphere Process Server, WebSphere 
Enterprise Service Bus, WebSphere Business Monitor, WebSphere Business 
Services Fabric, and WebSphere Dynamic Process Edition products. This 
chapter contains the following sections: 

► “Overview” on page 82 

► “Existing data consideration for runtime migration” on page 94 

► “Rollback from migration failure” on page 94 

► “Runtime migration general steps” on page 95 

► “Runtime migration for specific BPM products” on page 105 


© Copyright IBM Corp. 2010. All rights reserved. 
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3.1 Overview 


This section provides an overview for BPM version-to-version runtime migration. 


3.1.1 Runtime migration concepts 

With each new version, BPM products provide major functional improvements 
over previous versions. Typically, customers have a large investment in the 
configuration of their previous release profiles and they want to preserve that 
investment when moving to the latest release. In these circumstances, 
customers should perform a runtime migration, in particular if existing data is to 
be reused, for example, long-running BPEL instances, failed events, and so on. 
(Figure 3-1). 



Figure 3-1 BPM version to version runtime migration 


For those customers that simply want to reuse the applications and do not care 
about the existing profile configuration or the existing data, then a runtime 
migration is not necessary. An artifact migration (see Chapter 5, “Artifact 
migration” on page 123) or manual migration (see Chapter 4, “Manual migration” 
on page 117) can be done instead. If you have change in topology for the target 
version of the product, runtime migration might not be applicable. 

Runtime migration is profile-based, which means that you migrate profiles one by 
one, with the deployment manager (in network deployment environments) as the 
first profile to be migrated. 
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The target profile should not contain any user configuration or applications prior 
to migration if possible, as this can cause conflicts. When the migration detects a 
conflicting configuration between the old and new profile, the settings from the 
source profile are favored. If an application to be migrated is already installed on 
the target configuration, it will not be migrated. 

During version-to-version runtime migration, the existing product database 
schema also needs be updated with scripts provided by the product. 


Notes: 

1 . Reducing a profile’s functionality during a migration is not supported, for 
example, migrating a WebSphere Process Server profile to a WebSphere 
Enterprise Service Bus profile is not supported, regardless of release. 

2. For runtime migration, the target profile must have the exact same cell 
name and node name as those of the source profile. 


Runtime migration is done typically by using the following sequence: 

1 . Install the latest release of the product (beside the old version, not in place 
of). 

2. Run the migration wizard or command-line scripts to migrate each profile. 

3. Run the migration command to migrate any clusters that exist in the source 
environment. 

4. Update the product databases schema or data with provided scripts. 

Runtime migration involves profile migration and product database migration, and 
BPM products provide utilities to facilitate these migration tasks. You can migrate 
all of the profiles to latest version. Alternatively, you can just migrate some of the 
profiles, which will result in a mix-node (different level nodes co-existing) 
situation. Mixed-clusters (cluster members of the same cluster residing on 
different level nodes) is not supported. 

Profile migration 

Profile migration includes configuration migration and application migration. 

Configuration migration 

BPM runtime migration utilities automatically apply the configuration from a 
previous profile to the new profile. 
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Application migration 

In the context of the runtime migration method, application migration means 
installing an enterprise application from a previous profile to the new profile 
during the runtime migration process. Applications are installed as is during 
migration. Do not confused this migration with the artifact / application migration 
described in Chapter 5, “Artifact migration” on page 123. 

There are four types of applications to consider: 

► Sample application 

Sample applications provided with BPM products for demonstration purposes 
will not be migrated on a stand-alone topology, but will be migrated in a 
network deployment environment. 

► System application 

System applications refer to those applications under the 
<B/W_WCW£>/systemApps directory. Runtime migration will never migrate those 
system applications; instead, the new system applications will be used. 

► Product application 

Examples of product applications are Business Rule Manager and Business 
Process Choreographer. These applications will be migrated automatically. 

► User application 

User applications refer to those applications developed by the enterprise. 
Those applications will be migrated automatically. 

Refer to the following Information Center articles for more information at the 
following addresses: 

http : //publ ib. boulder. ibm. com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. websphere .wps . doc/doc/cmi g_vtv_bpmmi g_ovw.html 

http: //publ ib. boulder. i bm.com/infocenter/dmndhelp/V7. OrOmx/topi c/com. ib 
m. websphere .wps . doc/doc/cmi g_vtv_whatgets . html 

Product database migration 

In general, the migrated environment still uses the previous product databases 
and the existing data can be consumed by the migrated environment. 

In general, you do not need to create a new product database for the migrated 
environment manually, except in a data-only migration. However, the product 
database schema and product database structure might be updated if required 
and the data location might be changed from one table to another; these updates 
are done with the utilities shipped with BPM products. 
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BPM products provide scripts that perform product database migration. Some 
scripts can be invoked automatically when you start the migrated environment, 
but some scripts need to be invoked manually. As a best practice, run these 
product database migration scripts manually. 

After migration, the data source configuration on the migrated environment will 
be updated to point to the previous product databases. 

Some products, for example, WebSphere Business Monitor, support data-only 
migration for specific versions. For data-only migration, the existing data will be 
transferred from one product database to another product database with scripts 
provided by the product. If this is the case, you need to create new product 
databases for the new environment, as discussed in 3.5, “Runtime migration for 
specific BPM products” on page 105. 


3.1.2 Runtime migration versus an in-place upgrade 

In addition to runtime migration, there is another approach that allows you to use 
the new features of BPM products; it is called in-place upgrade or upgrade. An 
in-place upgrade refers to the replacement of a product with a newer version of 
that same product. Whether in-place upgrade is an option or not depends on the 
old and new product versions, as discussed in 3.5, “Runtime migration for 
specific BPM products” on page 105. 

You can do an in-place upgrade before or after version to version runtime 
migration, but you cannot do them both against one specific product version 
number pair. In-place upgrade is not part of version-to-version runtime migration. 
Table 3-1 compares the two options. 


Table 3-1 Runtime migration versus an in-place upgrade 


Item 

Runtime migration 

In-place upgrade 

New version product 
installation style 

The new version product is 
installed side-by-side the 
old release or on another 
machine (for stand-alone 
profile only). 

The new version product is 
installed on top of the old 
release under the same 
installation directory. 

Version number 

Applies to the first and 
second nd digit release 
number (count from left) 
changes, for example, 6.1 
to 6.2 or 6.2 to 7.0. 

Applies to third and fourth 
digit release number 
(count from left) changes 
(interim fixes, refresh 
packs, and fix packs), for 
example, 6.1 to 6.1.2 or 
6.1. 2.1 or 6.1. 2.3. 
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Item 

Runtime migration 

In-place upgrade 

Tools 

Use runtime migration 
specific tools (command or 
GUI wizard). 

Use WebSphere 
Application Server Update 
Installer or Installation 
Manager. 

Operation unit 

Repeat the migration 
procedure against each 
profile. Only the 
applications and 
configurations under that 
profile are migrated. 

Repeat the upgrade 
procedure against each 
installation directory, then 
all profiles under that 
installation will be 
upgraded. 


3.1.3 Runtime migration tools 

One of the major improvements in BPM V7.0 is that it delivers one new set of 
common commands and a user interface for version to version migration utilities 
across WebSphere Dynamic Process Edition, WebSphere Business Services 
Fabric, WebSphere Process Server, WebSphere Enterprise Service Bus, and 
WebSphere Business Monitor. 

Runtime migration command-line tools 

BPM V7.0 delivers a set of runtime migration command-line tools that can 
automatically identify the source profile template and migrate the profile 
(Figure 3-2). 


- Server Configuration 


- UUIIM 

I BPMSnapsho - Applications 

- Resources 


© 


| BPMCreateTargetProf Me^> 

r ® ^ 

| BPMMigrateProfile '> 



Steps 1 , 2, and 3 are mandatory for each profile. 
Step 4 is only mandatory for each cluster. 


Figure 3-2 Runtime migration command sequence 
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Runtime migration command-line tools are available on both distributed and 
z/OS platforms. Refer to the Information Center for all supported platforms at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/index.jsp7to 
pi c=/com. i bm. websphere. wps .doc/wel come_wps . html 

Table 3-2 lists all of the migration command line tools. For more detailed 
information about these commands, go to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps. doc/doc/rmi g_vtv_bpmsnapshot.html 


Table 3-2 Runtime migration commands 


Commands 

Description 

BPMSnapshotSourceProf i 1 e 

The BPMSnapshotSourceProf i 1 e command copies the 
configuration files in the source profile to a snapshot 
directory. 

BPMCreateTargetProf i 1 e 

The BPMCreateTargetProfile command creates a 
new profile that will be the migration target. The target 
profile is created with the same cell name, node name, 
and host name as specified in the source profile. 

BPMMigrateProfile 

The BPMMigrateProfile command migrates the 
source profile from the snapshot directory to the target 
profile. 

BPMMigrateCl uster 

The BPMMigrateCl uster command migrates cluster 
scope applications and configurations. You must 
execute this command for each cluster from the 
deployment manager node. 

BPMMigrationStatus 

The BPMMigrationStatus command displays the 
migration status. This command is not mandatory 


These commands only migrate applications and configurations under migration 
source profiles. They do not operate on data in the product databases. In order to 
complete the migration procedure, you must run additional product database 
upgrade scripts provided with the BPM products, as discussed in 3.4, “Runtime 
migration general steps” on page 95. 
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► On z/OS, you should not invoke these commands directly, but instead 
create customized jobs. 

► The migration command-line tools (WBIPreUpgrade, WBIPostUpgrade, 
WBIProfileUpgrade.ant, WBMPreUpgrade, WBMPostUpgrade) are still 
shipped with BPM V7.0, but they are deprecated. 

► The commands in Table 3-2 on page 87 are not applicable to WebSphere 
Business Compass migration. 

► You should always create the target profile using either the 
BPMCreateTargetProfile command or GUI migration tool (see “Runtime 
migration GUI wizard” on page 88), except in the following circumstances: 

- You are migrating from WebSphere ESB V6.0.2.X, in which case you 
should use the Profile Management tool. You can learn more about this 
tool by going to the following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi 
c/com. ibm. websphere. wesb.doc/doc/tmig_vtv_sidebysi decommandl ine 
.html 

- For the z/OS platform, the target profile is created with a customized 
job. 

Runtime migration GUI wizard 

BPM V7.0 also delivers a new GUI migration tool (Figure 3-3 on page 89). This 
tool is available for 32-bit BPM products on all distributed platforms. For 64-bit 
BPM products, it is available on Windows AMD-64, Windows x86-64, Linux 
x86-64, and HP-UNIX IA-64 platforms. The GUI migration tool is not available on 
the z/OS platform. 

You can invoke the GUI migration tool with the BPMMigrate script, found in the 
BPM_HOME/bir\ directory. The BPMMigrate GUI collects the relevant information 
from the user and executes the BPMSnapshotSourceProfile, 
BPMCreateTargetProfile, and BPMMigrateProfile commands in sequence. 
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The GUI migration tool is provided for your convenience, making it easier for you 
to walk through the steps needed for migration. The GUI migration tool provides 
two modes for providing migration parameters (Figure 3-3). The Typical migration 
mode performs the migration using a set of default values. The Custom migration 
mode provides more flexibility. If you want to specify the snapshot directory, 
target profile name, or assign port number for the target profile, then you need 
use the Custom migration mode. 



Figure 3-3 BPM runtime migration GUI wizard 


3.1.4 Runtime migration pattern 

When you plan your runtime migration, you can use full a downtime migration or 
minimal downtime migration approach. Migration without any downtime (also 
known as light-on migration ) is not supported. 
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Full downtime migration 

For full downtime migration, you need shut down the whole cell, including all 
application servers, all node agents, and the deployment manager, before you 
begin the migration procedure. No requests will be handled during the migration 
procedure. The length of the downtime depends on the number of nodes, 
number of applications, and the amount of data stored in the product databases. 

Full downtime migration is applicable to all source versions. You can do a 
consistent backup and restore for the source environment under full downtime 
migration. 

Minimal downtime migration 

For minimal downtime migration, the deployment manager is migrated first. While 
deployment manager migration is taking place, the application servers on other 
nodes are still available. 

After the migrated deployment manager has been migrated and started, migrate 
the nodes. 

If there are no clusters in the migration source environment, you can migrate 
each custom node, one at a time. As each node is migrated, the applications that 
run on the servers on that node will be out of service. 

If clusters exist in the migration source environment, you can migrate each 
cluster in phases if your cluster topology is suitable for this action. Stop and 
migrate the profiles for the nodes of half of the members for each cluster. While 
this migration is taking place, the second half of the cluster is available. 

When the first half is migrated, stop all the nodes with members in the cluster. 
Then migrate the cluster scope configuration and the databases. During this 
step, the applications on the cluster will be out of service. 

After the cluster migration, start the migrated nodes and cluster members, but 
keep the second half of the nodes stopped until you migrate them to Version 7.0. 

When you plan a minimal downtime migration, take the following factors into 
consideration. 

► The overall application unavailability time will be kept to a minimum. In the 
case of multiple clusters, the migration process can be spread over multiple 
maintenance windows: 

- Migration can be done for each cluster independently if their members are 
on different nodes. 

- Carefully analyze your topology for dependencies between clusters. 
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► In order to maintain some degree of application availability, some 
administrative restrictions must be put in place during the migration: 

- Do not install, update, or uninstall any applications that contain business 
processes, human tasks, or both. 

- Do not perform configuration activities for the Business Process 
Choreographer on the back level nodes. 

► There will be capacity restrictions. At times, a subset of the servers and 
clusters will be stopped, with only a subset of servers or clusters running. This 
can create: 

- A temporary reduction of availability. 

- Limited or no failover capabilities. 

► There are considerations for backup and restore. When performing the 
migration, the product databases might be used continuously. This means: 

- Consistent backup and rollback are more complicated. 

- Data created after the backup might be lost if a rollback is necessary. 


3.1.5 Runtime migration types 

This section describes the migration types. 

Side-by-side migration 

For side-by-side migration (Figure 3-4), the source product and the target 
product are located on the same system. Side-by-side migration is the typical 
migration type. You can do side-by-side migration for both stand-alone topologies 
and network deployment topologies. 



Figure 3-4 Side-by-side migration 
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Remote migration 

Remote migration (Figure 3-5) refers to the situation when the source product 
and the target product are located on different systems. Remote migration often 
involves cross machine remote migration. 


Note: Remote migration is only supported for stand-alone topologies on 
distributed platforms. 



Figure 3-5 Remote migration 


3.1.6 Runtime migration from 32-bit products to 64-bit products 

This section describes the migration from 32-bit BPM products to 64-bit BPM 
products in cases where the target product has a 64-bit build. 

The operating system is already a 64-bit platform 

In this scenario, you simply need to install the 64-bit target product on the 
existing operating system and do a side-by-side migration. 

The operating system is 32-bit, and is easily switched to 64-bit 

For some operating systems, for example, AIX®, you can easily switch from 
32-bit mode to 64-bit mode. If that is the case, you need to switch the operating 
system from 32-bit mode to 64-bit mode first, then do a side-by-side migration 
with the 64-bit product. 
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The operating system is 32-bit and must be re-installed as 
64-bit 

This scenario is much more complicated. First, you need to install a new 64-bit 
operating system. For a stand-alone environment, you need to perform the 
following steps: 

1 . Generate the remote migration utilities with the 
BPMCreateRemoteMigrationUtilities tool on a 32-bit system with the newer 
version 32-bit product. 

2. With the generated remote migration utilities, on the 32-bit system with the old 
version of the product, run the BPMSnapshotSourceProfile command to 
generate the snapshot directory. 

3. On the 64-bit system with the newer version 64-bit product, perform the 
migration with the generated snapshot directory. 

For network deployment environments, this type of migration is not supported, 
because it involves remote migration. The recommended approach in this case is 
to do a manual migration. 

3.1.7 Runtime migration with a non-root user 

If you set up the previous version environment with the root user, but now plan to 
use a non-root user for the setup of the Version 7.0 products, then you need take 
special consideration when you plan your runtime migration. 

Basically, the BPMSnapshotSourceProfile command needs access to the 
previous version’s profile directory to back up the configurations and applications. 
If the non-root user does not have access to the original file structure, you will 
see a migration failure. 

Grant the non-root user read access to the <vPrevious_Instal lation> and 
<vPrevious_Profile_Root> directories. Also, you should grant the non-root user 
write access to the <vPrevious_Profile_Root >/ config directory. 

Example commands are shown in Example 3-1. 

Example 3- 1 Granting the proper access to the non-root user 

chown -R nonroot_user <vPrevious_Installation> 
chown -R nonroot_user <vPrevious_Profile_Root> 


Note: WebSphere Business Services Fabric V7.0 does not support non-root 
installation, so you cannot migrate to WebSphere Business Services Fabric 
V7.0 using a non-root user. 
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3.2 Existing data consideration for runtime migration 


After the runtime migration, data generated before the migration is still used. For 
example, long-running BPEL process instances are converted into new schema 
and automatically continue running, previous failed events can be resubmitted 
after migration, and previous WebSphere Business Services Fabric content 
archives can be used. 

As best practice, resolve all in-doubt transactions, handle all in-flight messages 
where possible, and clean up all exceptions in the log before starting your 
migration. 


3.3 Rollback from migration failure 

As a best practice, take a full backup before the runtime migration. Full backup 
means a backup of all profiles and all product databases. Such a backup is 
mandatory for a rollback from a migration failure. As another best practice, take 
backups often during the migration procedure for a quick rollback. 

In general, if there is a failure when you execute one migration command, you 
need to roll back to a specific backup point and rerun all of the migration 
commands after that backup point. You should not rerun the migration command 
against an environment that has a migration failure. However, if the failure 
happens when you execute the BPMMigrationCluster command, you can rerun 
the command multiple times without a rollback. 

For more backup and restore information, refer to the following items: 

► For distributed systems, go to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . doc/doc/tmi g_vtv_rol 1 back . html 

► For z/OS systems, go to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . z . doc/doc/tmi g_vtv_rol 1 back . html 
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3.3.1 Rollback for full downtime migration 


For a full downtime migration, it is easy to take a full backup. Perform the 
following steps: 

1 . Use a tar command to back up the entire installation directory for the old 
products. If the profiles or other artifacts are located in a directory other than 
the installation directory, be sure to back them up as well. Other artifacts 
include transaction log files on a shared disk, external jars, and any other 
external files used. 

2. Back up all product databases with database tools, for example, db2 backup 
db db name for a DB2 database. 

If there is a failure during the migration, simply restore these backups and redo 
your migration. 

See 6.3.9, “Back up the source environment” on page 218 for an backup 
example. 


3.3.2 Rollback for minimal downtime migration 

For a minimal downtime migration, it is not easy or might even be impossible to 
find a point to back up the product databases, because the databases will be 
used continuously during the migration and the data might be updated. Data 
created after the backup might be lost. 


3.4 Runtime migration general steps 

This section describes the runtime migration general steps with a sample 
topology. The following general steps apply to WebSphere Process Server, 
WebSphere Enterprise Service Bus, WebSphere Business Monitor, WebSphere 
Business Services Fabric, and WebSphere Dynamic Process Edition. Different 
products or different versions of the same product might have slight differences in 
the migration steps. Also refer to 3.5, “Runtime migration for specific BPM 
products” on page 105 and Chapter 2, “Release-specific information” on 
page 47. 


3.4.1 Runtime migration for a stand-alone profile 

This section describes the general runtime migration steps for migrating a 
stand-alone profile topology. 
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Sample topology 

Figure 3-6 shows the details of a stand-alone profile topology. 


Machine A 


Standalone Profile 


Application 


Figure 3-6 Stand-alone profile topology 

The key details of this topology are that there is one stand-alone profile, no node 
agents, and no clusters. 

The topology described in Figure 3-6 only supports a runtime migration with full 
downtime. However, it supports both side-by-side migration and remote 
migration. 

High level steps for side-by-side migration 

In order to migrate the stand-alone profile topology side-by-side, you need to 
perform these general steps: 

1 . Check the Information Center for BPM products to collect the system 
requirements for the Version 7.0 products, including the operating system and 
product database levels required. See 3.5, “Runtime migration for specific 
BPM products” on page 105 for the system requirement link for your specific 
product. 

2. Stop the migration source stand-alone application server. 

3. Back up the migration source environment, including product databases. 

4. If necessary, upgrade the operating system and product database level 
according to the system requirement information collected from step 1 . 

5. Back up the product databases of the migration source environment again if 
you upgraded the product database level. 

6. Install the migration target product(s) side-by-side with the migration source 
product(s). 
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7. Invoke the BPM runtime migration tools in the following order to migrate the 
stand-alone profile. See 3.1.3, “Runtime migration tools” on page 86 for more 
details: 

a. BPMSnapshotSourceProfileBPM 

b. CreateTargetProfile 

c. BPMMigrateProfile 

Note: Alternatively, you also can use the BPMMigrate GUI migration 
tool to migrate the stand-alone profile. 

8. Copy the product database upgrade scripts from the target machine to the 
product database server. See 6.5.2, “Upgrade common database schema” on 
page 250 for an example. 

9. On the product database server, execute the product database upgrade 
scripts to update the product database schema and data. 

10. Update the JDBC driver on each BPM V7.0 installation according to your 
product database type and level. By default, BPM products only provides a 
JDBC driver for DB2 databases. 

1 1 .If you have manually placed artifact files (for example, jar files and scripts) in 
your migration source environment, then you need to copy them to your 
migration target environment manually. 

12. Complete the post-migration tasks. Refer to the Information center found at 
the following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/index. jsp 

13. The information found there gives the post-migration tasks against a specific 
product and version. 

14. Back up the migration target environment, including profiles and product 
databases. This step is not necessary but recommended. 

15. Start the migration target environment. 

16. Verify the migration target environment. 

High level steps for remote migration 


Note: BPM products do not support: 

► Remote migration for the z/OS platform. 

► The GUI migration tool for remote migration. 
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In order to migrate the stand-alone profile topology remotely, you need to perform 

these general steps: 

1 . Check the Information Center for BPM products to collect the system 
requirements for the Version 7.0 products, including the operating system and 
product database levels required. See 3.5, “Runtime migration for specific 
BPM products” on page 105 for the system requirement link for your specific 
product. 

2. Install the new system according to the system requirements collected in step 

1 . 

3. Install the migration target product(s) on the new system. 

4. On the new system, generate the remote migration utilities image with the 
BPMCreateRemoteMigrationUtilities command. Refer to 3.1.3, “Runtime 
migration tools” on page 86 for more information. 

5. Copy the remote migration utilities image to the migration source 
environment. 

6. Stop the stand-alone application server of the migration source environment. 

7. Back up the migration source environment, including product databases. 

8. On the migration source environment, invoke the BPMSnapshotSourceProfile 
command to generate a profile snapshot. The command is contained in the 
remote migration utilities image. Refer to 3.1 .3, “Runtime migration tools” on 
page 86 for more information. 

9. Copy the generated profile snapshot directory from the migration source 
environment to the migration target environment. 

10. On the migration target environment, execute the BPMCreateTargetProfile 
and BPMMigrateProfile commands against the profile snapshot directory to 
migrate the profile. 

1 1 .On the product database server, execute the product database upgrade 
scripts to update the product database schema and data. 

12. Update the JDBC driver on each BPM Version 7.0 installation according to 
your product database type and level. By default, BPM products only provide 
JDBC drivers for DB2 databases. 

13. If you have manually placed artifact files (for example, jar files or scripts) in 
your migration source environment, then you need copy them to your 
migration target environment. 

14. Complete the post-migration tasks. Check the Information Center at the 
following address for the specific product and version: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/index. jsp 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 


15. Back up the migration target environment, including profiles and product 
databases. This step is not necessary but recommended. 

16. Start the migration target environment. 

17. Verify the migration target environment. 

3.4.2 Runtime migration for network deployment with cluster 

This section describes the general runtime migration steps for migrating a 
network deployment topology with clusters. 

Sample topology 

Figure 3-7 shows the details of the sample network deployment topology with a 
single cluster. 
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Note that: 

► There is one deployment manager profile with two custom profiles. This 
diagram has been simplified to show the concepts of migration. In a typical 
environment, there can be more custom profiles. 

► The topology is comprised of multiple application servers and node agents. 

► There is one cluster with business applications. 

This topology supports both runtime migration with full downtime and runtime 

migration with minimal downtime.The topology described in Figure 3-7 on 

page 99 only supports the side-by-side migration type. 

High level steps for runtime migration with full downtime 

In order to migrate the topology described in Figure 3-7 on page 99 in a full 

downtime manner, perform the following steps: 

1 . Check the Information Center for BPM products to collect the system 
requirements for the Version 7.0 products, including the operating system and 
product database levels required. See 3.5, “Runtime migration for specific 
BPM products” on page 105 for the system requirement link for your specific 
product. 

2. Stop the deployment manager, all node agents, and all application servers in 
the migration source environment. 

3. Back up the whole migration source environment, including all installation 
directories, all profile directories, and all product databases. 

4. If necessary, upgrade all of the operating systems and product database 
levels according to the system requirement information collected from step 1. 

5. Back up the product databases of the migration source environment again if 
you upgraded the product database level. 

6. Install the migration target product(s) side-by-side with the migration source 
product(s) on machine A. This machine hosts the deployment manager 
profile. 

Note: For a network deployment environment, the deployment manager 
profile must be migrated first before any other profiles. 

7. Invoke the BPM runtime migration tools in the following sequence to migrate 
the deployment manager profile. See 3.1 .3, “Runtime migration tools” on 
page 86 for more information: 

a. BPMSnapshotSourceProfile 

b. BPMCreateTargetProfile 
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c. BPMMigrateProfile 


Note: Alternatively, you also can use BPMMigrate GUI migration tool to 
migrate the profile. 


8. Copy the product common database upgrade scripts from the BPM target 
machine to the product database server. See 6.5.2, “Upgrade common 
database schema” on page 250 for an example. 

9. On the product database server, execute the product database upgrade 
scripts to update the schema of the common database. 

10. Update the JDBC driver on each BPM V7.0 installation according to your 
product database type and level. By default, BPM products only provide 
JDBC drivers for DB2 databases. 

1 1 .If you have manually placed artifact files (for example, jar files and scripts) in 
your migration source environment, then copy them to your migration target 
environment. 

12. Start the deployment manager in the migration target environment. 

13. Install the migration target product(s) side-by-side with the migration source 
product(s) on machine B. This machine hosts one of the custom profiles. 


Note: If there are pure WebSphere Application Server custom profiles in 
your topology, migrate those custom profiles before others. You can use the 
migration tool to migrate those custom profiles. 


14. Invoke BPM runtime migration tools in the following sequence to migrate the 
custom profile on machine B. See 3.1 .3, “Runtime migration tools” on page 86 
for more information: 

a. BPMSnapshoutSourceProfile 

b. BPMCreateTargetProfile 

c. BPMMigrateProfile 


Note: Alternatively, you can use the BPMMigrate GUI migration tool to 
migrate the custom profile. 


15. Repeat steps 13 through 15 to migrate the next custom profile on machine C, 
and each additional machine where you have custom profiles. 
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16. From the migration target deployment manager, execute the 
BPMMigrateCluster command against each cluster to migrate the cluster 
scope configuration. If you have multiple clusters, then repeat the 
BPMMigrateCluster command against each cluster, one by one. 

17. Back up the migration target profiles. This backup will be needed if you run 
into errors, such as an OutOfMemory exception in the next step. 

18. For each migration target custom node that hosts cluster members, execute 
the <B/W_/?00r>/bin/syncNode command to synchronize the node 
configuration with the target deployment manager. 

19. On the product database server, execute the product database upgrade 
scripts to update the product database schema and data for other product 
databases, for example, the database for Business Process Choreographer 
and the database for Business Space. See 6.5.13, “Update the BPC 
database” on page 289 for an exact example. 

20. Update the JDBC driver on each BPM V7.0 installation on the custom node 
machines B and C. By default, BPM products only provide JDBC drivers for 
DB2 databases. 

21 . If you have manually placed artifact files (for example, JAR files and scripts) in 
your migration source environment, then copy them to your migration target 
environment. 

22. Complete the post-migration tasks. Please check the Information Center for 
the specific product and version at the following address: 

http : //publ I b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/i ndex . j sp 

23. Back up the migration target environment, including profiles and product 
databases. This step is not necessary but is recommended. 

24. Start the migration target environment. 

25. Verify the migration target environment. 

High level steps for runtime migration with minimal downtime 

In order to migrate the topology described in Figure 3-7 on page 99 in a minimal 

downtime manner, perform the following steps: 

1 . Check the Information Center for BPM products to collect the system 

requirements for the Version 7.0 products, including the operating system and 
product database levels required. See 3.5, “Runtime migration for specific 
BPM products” on page 105 for the system requirement link for your specific 
product. 
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2. For each cluster, identify the profiles that need be migrated to the same level 
and categorize them into several groups. Divide the profiles that contain 
servers that contribute to the cluster into two roughly equivalent sized groups, 
group A and group B. 

In this example, group A consists of the servers and node agents on machine 

B. Group B consists of the application servers and node agents on machine 

C. 

3. Use the administrative console on the source deployment manager to disable 
synchronization for all nodes. This step is mandatory for minimal downtime 
migration. 

4. Stop the deployment manager and keep all of the other node agents and 
application servers running. 

5. Back up the source deployment manager profile and common database. 

6. If necessary, upgrade the operating system of machine A and product 
database level according to the system requirement information collected 
from step 1 . 

7. Back up the common database just in case you have upgraded the product 
database level. 

8. Install the migration target product(s) side-by-side with the migration source 
product(s) on machine A, which hosts deployment manager profile. 

Note: For a network deployment environment, the deployment manager 
profile must be migrated before any other profiles. 

9. Invoke the BPM runtime migration tools in the following sequence to migrate 
deployment manager profile. See 3.1 .3, “Runtime migration tools” on page 86 
for more information: 

a. BPMSnapshotSourceProfile 

b. BPMCreateTargetProfile 

c. BPMMigrateProfile 


Note: Alternatively, you can use GUI migration tool BPMMigrate to 
migrate the profile. 


1 0.Copy the provided product database upgrade scripts for the product database 
used by the target deployment manager from the BPM profile machine to 
product database server. 


Chapter 3. Runtime migration 103 





1 1 .On the product database server, execute the product database upgrade 
scripts to update the schema of the product database used by the target 
deployment manager. 

12. Update the JDBC driver on each BPM Version 7.0 installation on machine A. 
By default, BPM products only provide JDBC drivers for DB2 databases. 

13. If you have manually placed artifact files (for example, JAR files and scripts) in 
your migration source environment, copy them to your migration target 
environment. 

14. Start the deployment manager in the migration target environment. 

15. Stop the application servers and node agents in group A (the application 
servers and node agents on machine B). 

16. Back up the custom profile in group A. 

17. If necessary, upgrade the operating system for the machine that hosts group 
A profiles and the product database level used by the applications in group A 
according to the system requirement information collected from step 1 . 

18. Install the migration target product(s) side-by-side with the migration source 
product(s) on machine B. 

19. Invoke BPM runtime migration tools in the following sequence to migrate 
Custom Profile 1 on in group A. See 3.1.3, “Runtime migration tools” on 
page 86 for more information: 

a. BPMSnapShotSourceProfile 

b. BPMCreateTargetProfile 

c. BPMMigrateProfile 


Note: Alternatively, you can use the GUI migration tool BPMMigrate to 
migrate the profile. 


20. If you have manually placed artifact files (for example, JAR files and scripts) in 
your migration source environment, copy them to your migration target 
environment. 

21. If there are more custom profiles in group A, repeat steps 15 through 20. 

22. Stop all application servers and node agents in group B. At this point, you 

have complete downtime of your applications. 

23. From the migration target deployment manager, execute the 

BPMMigrateCluster command against the cluster that contains the group A 
custom profiles. This will migrate the cluster scope configuration. 
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24. From the administrative console of the migration target deployment manager, 
enable synchronization for all nodes in the migrated cluster (both group A and 
group B). 

25. Back up the migrated profiles in group A; for this example, it is custom profile 
1. 

26. For each migration target custom profile in group A, execute the syncNode 
command against the migration target deployment manager. 

27. Copy the provided product database upgrade scripts for the product 
databases (used by the cluster that has just been migrated) from the BPM 
profile machine to the product database server. 

28. On the database server, execute the database upgrade scripts to update the 
schema for the product databases used by migrated cluster. 

29. Update the JDBC driver on each BPM Version 7.0 installation for group A. By 
default, BPM products only provide JDBC drivers for DB2 databases. 

30. Complete the post-migration tasks for group A profiles. Please check the 
Information Center for the specific product and version at the following 
address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/index. jsp 

31 .Start the migrated node agent and application servers in group A; for this 
example, it is the application servers and node agents on machine B. 

32. For the custom profiles in group B, repeat steps 15 through 20 to migrate 
them. 

33. Back up the migrated profiles in group B; for this example, it is custom profile 
2. 

34. For each migration target custom profile in group B, execute syncNode against 
the migration target deployment manager. 

35. Start the migrated node agents and application servers in group B. 

36. If there are more clusters in your environment, repeat steps 15 through 35 to 
migrate those clusters one by one. 


3.5 Runtime migration for specific BPM products 

This section describes product specific runtime migration information. 


WebSphere Adapters: If you use any WebSphere Adapters for Version 6.0.2 
or WebSphere Adapter for SAP V6.0.2, V6.1 .0, V6.1 .2, and V6.2.0, see 2.6.3, 
“Known limitations for WebSphere Adapters” on page 79 for more information. 
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For z/OS installations, you might also find the following documents useful when 
planning for your migration: 

► WebSphere Application Server for z/OS Migration Performance Study, found 
at the following address: 

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP10158 

9 

► Migrating to WebSphere z/OS V7.0, found at the following address: 
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP10132 
9 

3.5.1 Runtime migration for WebSphere Process Server 

WebSphere Process Server environments running Version 6.0.2.x, 

Version 6.1 .0.x, Version 6.1 .2.x, or Version 6.2.0.x can migrate to Version 7.0 
directly with either full downtime migration or minimal downtime migration. 
Alternatively, you can migrate WebSphere Process Server to Version 7.0 
indirectly, that is, you migrate an existing WebSphere Process Server to a 
pre-Version 7.0 version first, then further migrate to Version 7.0. WebSphere 
Process Server does not support data-only migration. 

WebSphere Process Server V6.1 is the first version to support runtime migration 
capability. WebSphere Process Server V6.2.0.X and V6.2.X do not support 
minimal downtime migration from Version 6.0.2.x. 

If you are migrating to WebSphere Process Server V7.0 in a minimal downtime 
approach and your applications use mediation flow components or business 
calendar, then before the nodes that host such applications are migrated to 
Version 7.0, those applications cannot start; this is a known limitation. 

Check the information in the following links before you start the migration: 

► WebSphere Process Server system requirement, which can be found at the 
following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27006205 

► Runtime pre-migration checklist for distributed platform, which can be found at 
the following address: 

http : // publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm . websphere . wps . doc/doc/cmi g_vtv_premi gcheckl i st . html 
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Deprecated features for distributed platform, which can be found at the 
following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm. websphere . wps . doc/doc/gmi g_deprecati on! i st . html 
Known compatibility issues for distributed platform, which can be found at the 
following address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm .websphere . wps . doc/doc/cmi g_vtv_compat . html 

Runtime pre-migration checklist for z/OS, which can be found at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
. i bm. websphere .wps . z . doc/doc/cmi g_vtv_premi gcheckl i st . html 
Deprecated features for z/OS, which can be found at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . z . doc/doc/gmi g_deprecat i onl i st . html 
Known compatibility issues for z/OS, which can be found at the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wps . z . doc/doc/cmi g_vtv_compat . html 
Recommended fixes for WebSphere Process Server, which can be found at 
the following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2307&ui d=swg27006649 
Recommended interim fixes for installing WebSphere Process Server 
V7.0. 0.0.0, which can be found at the following address: 
http: //www-01. ibm. com/support/docvi ew.wss?uid=swg21414253 
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Table 3-3 shows the migration matrix for WebSphere Process Server. As a best 
practice, use the latest versions of WebSphere Process Server for migration 
purposes. 


Table 3-3 WebSphere Process Server migration matrix 


To 

From 

Version 

6.0.2.y a 

Version 
6.1 .0.y 

Version 
6.1 .2.y 

Version 6.2.y 

Version 

7.0.0.y 

Version 

6.0.1.x 

Upgrade 

Migrate 

Migrate 

b 

b 

Version 

6.0.2.x 

Upgrade 

Migrate 

Migrate 

Migrate 

Migrate 

Version 

6.1.0.x 

N/A 

Upgrade 

Upgrade 

Migrate 

Migrate 

Version 

6.1.2.x 

N/A 

N/A 

Upgrade 

Migrate 

Migrate 

Version 6.2.x 

N/A 

N/A 

N/A 

Upgrade 

Migrate 

Version 

7.0.0.x 

N/A 

N/A 

N/A 

N/A 

Upgrade 


a. The number represented by y is larger than the number represented by x. 


b. To get from Version 6.0.1 .x to Version 6.2.x or Version 7.0, you must first upgrade from Version 
6.0.1.x to Version 6.0.2.x, then migrate Version 6.0.2.x to Version 6.2.x or Version 7.0. You cannot 
directly migrate WebSphere Process Server Version 6.0.1 .x to Version 6.2.x or Version 7.0.0.x. 


3.5.2 Runtime migration for WebSphere Enterprise Service Bus 

WebSphere Enterprise Service Bus environments running Version 6.0.2.x, 
Version 6.1 .0.x, Version 6.1 .2.x, or Version 6.2.0.x can migrate to Version 7.0 
directly with either full downtime migration or minimal downtime migration. 
Alternatively, you can migrate WebSphere Enterprise Service Bus to Version 7.0 
indirectly. WebSphere Enterprise Service Bus does not support data-only 
migration. 

For minimal downtime migration, applications that exploit business calendars or 
mediation flow components will remain stopped automatically until the node is 
migrated to Version 7.0. This means that during minimal downtime migration, 
your applications that have business calendars or mediation flow components 
cannot remain up on the un-migrated half of the cluster members and they will be 
out of service for a period of time. 
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Check the following information before you start the migration: 

► WebSphere Enterprise Service Bus system requirement, which can be found 
at the following address: 

http: //www-01. ibm.com/support/docview.wss?uid=swg270069 12 

► Runtime pre-migration checklist for distributed platform, which can be found at 
the following address: 

http : //publ i b.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm .websphere . wesb . doc/doc/cmi g_vtv_premi gcheckl i st . html 

► Deprecated features for distributed platform, which can be found at the 
following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
. ibm. websphere. wesb. doc/ref /rwesb_deprecationl ist.html 

► Known compatibility issues for distributed platform, which can be found at the 
following address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm .websphere . wesb . doc/doc/cmi g_vtv_compat . html 

► Runtime pre-migration checklist for z/OS, which can be found at the following 
address: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. ibm. websphere. wesb. zseries. doc/doc/cmi g_vtv_premi gcheckl ist.html 

► Deprecated features for z/OS, which can be found at the following address: 
http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm. websphere .wesb . zseri es .doc/ref /rwesb_deprecati onl i st . html 

► Known compatibility issues for z/OS, which can be found at the following 
address: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm .websphere . wesb . zseri es . doc/doc/cmi g_vtv_compat . html 

► Recommended fixes for WebSphere Enterprise Service Bus, which can be 
found at the following address: 

http: //www-01. i bm.com/support/docview. wss?uid=swg27007485 
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Table 3-4 shows the migration matrix for WebSphere Enterprise Service Bus. As 
a best practice, use the latest versions of WebSphere Enterprise Service Bus for 
migration purposes. 


Table 3-4 WebSphere Enterprise Service Bus migration matrix 


To 

From 

V6.0.2.y a 

V6.1.0.y 

V6.1.2.y 

V6.2.y 

V7.0.0.y 

V6.0.1.X 

Upgrade 

Migrate 

Migrate 

b 

b 

V6.0.2.X 

Upgrade 

Migrate 

Migrate 

Migrate 

Migrate 

V6.1.0.X 

N/A 

Upgrade 

Upgrade 

Migrate 

Migrate 

V6.1.2.X 

N/A 

N/A 

Upgrade 

Migrate 

Migrate 

V6.2.X 

N/A 

N/A 

N/A 

Upgrade 

Migrate 

V7.0.0.X 

N/A 

N/A 

N/A 

N/A 

Upgrade 


a. The number represented by y is larger than the number represented by x. 


b. To get from Version 6.0.1.x to Version 6.2.x or Version 7.0, you first upgrade from Version 6.0.1.x to 
Version 6.0.2.x, then migrate Version 6.0.2.x to Version 6.2.x or Version 7.0. You cannot directly 
migrate WebSphere Enterprise Service Bus Version 6.0.1.x to Version 6.2.x or Version 7.0.0.x. 


3.5.3 Runtime migration for WebSphere Business Monitor 

If you are migrating WebSphere Business Monitor V6.0.2 to Version 7.0, then you 
need do both artifact migration to migrate the monitor models and data-only 
runtime migration to migrate the existing data to a new product database. For 
more information about this topic, go to the following address: 
http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_602 . html 

You can also migrate WebSphere Business Integration Monitor V4.2.4 FDL 
models and historical runtime data to Version 7.0. For more information about 
this topic, go to the following address: 

http : //publ i b . boul der.i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_424 . html 

Starting with WebSphere Business Monitor V7.0, the Alphablox repository is in 
the WebSphere Business Monitor product database by default. Regardless of the 
previous WebSphere Business Monitor version implemented, you must migrate 
the existing Alphablox repository to the WebSphere Business Monitor V7.0 
product database repository. 
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To migrate WebSphere Business Monitor V6.1 .x to Version 7.0, go to the 
following address: 

http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m . btool s . hel p .moni tor .mi g . doc/mi g/mi g_61 . html 

To migrate WebSphere Business Monitor version 6.2.x to Version 7.0, go to the 
following address: 

http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m . btool s . hel p .moni tor .mi g . doc/mi g/mi g_62_ov . html 

See Chapter 6, “Migrating BPM V6.1.2 to WebSphere Dynamic Process Edition 
V7.0” on page 195 for a detailed migration example. 

Check the following resources for information before you start the migration: 

► WebSphere Business Monitor system requirement, which can be found at the 
following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=802&context=SSSRR3&ui d= 
swg27016838 

► Recommended fixes for WebSphere Business Monitor, which can be found at 
the following address: 

http: //www-01. ibm. com/support/docvi ew.wss?uid=swg27010921 
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Table 3-5 shows the migration matrix for WebSphere Business Monitor. As a best 
practice, use the latest versions of WebSphere Business Monitor for migration 
purposes. 


Table 3-5 WebSphere Business Monitor migration matrix 


To 

From 

Version 

6.0.2.y 

Version 
6.1. 0.y 

Version 
6.1. 2.y 

Version 6.2.y 

Version 

7.0.0.y 

Version 

6.0.1.x 

Upgrade 

Migrate 

Migrate 

a 

a 

Version 

6.0.2.x b 

Upgrade 

Migrate 

Migrate 

Migrate 

Migrate 

Version 

6.1.0.x 

N/A 

Upgrade 

Upgrade 

Migrate 

Migrate 

Version 

6.1.2.x 

N/A 

N/A 

Upgrade 

Migrate 

Migrate 

Version 6.2.x 

N/A 

N/A 

N/A 

Upgrade 

Migrate 

Version 

7.0.0.x 

N/A 

N/A 

N/A 

N/A 

Upgrade 


a. To get from Version 6.0.1 .x to Version 6.2.x or Version 7.0, you first upgrade from Version 6.0.1 .x 
to Version 6.0.2.x, then migrate Version 6.0.2.x to Version 6.2.x or Version 7.0. You cannot directly 
migrate WebSphere Enterprise Service Bus Version 6.0.1 .x to Version 6.2.x or Version 7.0.0.x. 


b. If you are using WebSphere Business Monitor V6.0.2.1 , you must install interim fix 5 or higher for 
WebSphere Business Monitor V6. 0.2.1 before beginning the migration process. For more 
information, go to the following address: 
http: //www-01. 1bm.com/support/docview.wss?u1d=swg27010921#602 

WebSphere Business Monitor does not support z/OS. 

3.5.4 Runtime migration for WebSphere Business Services Fabric 

The standard runtime migration tooling support for WebSphere Business 
Services Fabric was introduced in Version 7.0. WebSphere Business Services 
Fabric-specific profiles and Profile Management Tool support were introduced 
only in Version 6.2. In versions prior to Version 6.2, WebSphere Business 
Services Fabric applications was installed on a WebSphere Process Server-only 
profile. 

For WebSphere Business Services Fabric V6.1 .2.x, if it is part of the stack being 
migrated, you could still migrate WebSphere Business Services Fabric using the 
runtime migration tool (see 3.1.3, “Runtime migration tools” on page 86) with 
some workarounds. 
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To implement these workarounds, perform the following steps: 

1 . Export the WebSphere Business Services Fabric ontology content archive 
and dependency archives for your prior projects that you need to migrate 
using the WebSphere Business Services Fabric administrative console. 

2. Install WebSphere Business Services Fabric V7.0 with no profiles. 

3. Migrate from earlier releases (prior to Version 6.2) using the standard runtime 
migration tool. This would migrate WebSphere Business Services Fabric 
applications also on that WebSphere Process Server profile. 

4. Augment the migration target profiles that host WebSphere Business 
Services Fabric product applications. This is required to get the profile 
branding capability introduced in Version 7.0. 

5. Import the data exported from Step 1 into WebSphere Business Services 
Fabric V7.0 using the WebSphere Business Services Fabric administrative 
console. 

6. Drop the previous WebSphere Business Services Fabric product database, 
as that product database is no longer used since Version 6.2. All WebSphere 
Business Services Fabric repository data is stored in the WebSphere Process 
Server common product database now. 

If you are migrating WebSphere Business Services Fabric V6. 0.2.x to Version 

7.0, you should migrate the Version 6.0.2.x runtime to Version 6.1.x first, as 

detailed in the following steps, and then migrate the Version 6.1 .x runtime to 

Version 7.0 with the above workaround. 

Perform the following steps: 

1 . Migrate WebSphere Business Services Fabric database manually as 
documented in the Information Center found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. ibm.ws. fabric. mi gr. doc/mi gr602/concept/c_migfabricdbfrom6.0.2to6. 1. 
html 

2. Run the FabricDBMigrationUtility utility. 

3. Install the new WebSphere Business Services Fabric V6.1 .x runtime. 

4. Install the WebSphere Business Services Fabric V6.1 .x applications and 
create the required artifacts manually. For more information about this topic, 
go to the following address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/v6rlmx/topi c/com. i 
bm. ws . fabri c . i nstal 1612. doc/f pi /concept/c_wbsf_packagi ng . html 
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5. Remove the LDAP configuration by using the WebSphere Business Services 
Fabric administrative console. For more information about this topic, go to the 
following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm . ws . f abri c .mi gr . doc/mi gr602/concept/c_mi gf abri cdbf rom6 . 0 . 2to6 . 1 . 
html 

Please check the following information before you start the migration: 

► WebSphere Business Services Fabric system requirement, which can be 
found at the following address: 

http://www-01.ibm.com/software/integration/wbsf/sysreqs/index.html 

► Recommended Fixes for WebSphere Business Services Fabric, which can be 
found at the following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27008650 


3.5.5 Runtime migration for WebSphere Dynamic Process Edition 

Before Version 7.0, a typical WebSphere Dynamic Process Edition network 
deployment topology consisted of a WebSphere Process Server profile, a 
WebSphere Business Monitor profile, and a WebSphere Business Services 
Fabric profile. To migrate such a topology, you need to complete the migration for 
each of those profile types and perform the post-migration tasks for each of 
involved products. See Chapter 6, “Migrating BPM V6.1 .2 to WebSphere 
Dynamic Process Edition V7.0” on page 195 for an example of such a migration. 

Please check the following resource for information before you start the 
migration: 

► WebSphere Dynamic Process Edition system requirement, which can be 
found at the following address: 

http: //www-01 . i bm. com/software/i ntegrati on/wdpe/requi rements 
Table 3-6 shows the migration matrix for WebSphere Dynamic Process Edition. 


Table 3-6 WebSphere Dynamic Process Edition migration matrix 


To 

From 

Version 6.1. 2.y 

Version 6.2.y 

Version 7.0.0.y 

Version 6.1.2.x 

Upgrade 

Migrate 

Migrate 

Version 6.2.x 

N/A 

Upgrade 

Migrate 

Version 7.0.0.x 

N/A 

N/A 

Upgrade 
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3.5.6 Runtime migration for WebSphere Business Compass 


IBM WebSphere Business Compass is the new name for IBM WebSphere 
Business Modeler Publishing Server. This new offering combines the reviewing 
and publishing function of WebSphere Business Modeler Publishing Server with 
the business design authoring collaboration function of the WebSphere Business 
Modeler Publishing Server V6.2 Feature Pack. Business Compass provides a 
single, comprehensive authoring and reviewing environment for business users. 

If you have installed Version 6.2.x, Version 6.1.x, or Version 6.0.2.x of 
WebSphere Business Modeler Publishing Server, then you can migrate to 
WebSphere Business Compass V7.0. 

WebSphere Business Compass V7.0 only supports data only migration. 

See the Information Center for more information by going to the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.btool s.hel p. modeler. col lab. publ ish. mi g. doc/mi g/mi grate.html 
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Manual migration 


This chapter addresses general considerations when manually migrating a 
Business Process Management (BPM) runtime to BPM V7.0. In this chapter, we 
will discuss the manual migration of WebSphere Process Server, WebSphere 
Enterprise Service Bus, WebSphere Business Monitor, WebSphere Business 
Services Fabric, and WebSphere Dynamic Process Edition products. 

This chapter contains the following sections: 

► “Manual migration concepts” on page 118 

► “Manual migration steps” on page 120 
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4.1 Manual migration concepts 

If you require the same configuration in your target environment as your source 
environment, then the runtime migration method is typically more appropriate, 
because it will automatically replicate the source environment's topological 
configuration to the target environment. However, if you need to reconfigure the 
target environment configuration to be completely different than your source 
environment, you must either do it before or after version-to-version migration as 
an independent exercise, or use the manual method if you plan to do it 
concurrent with the version-to-version migration. 

The parallel environments provided by the manual migration method enables a 
target production environment that is completely independent of the source 
environment that is serving the existing consumers enabling the target 
environment to be rigorously tested before going live in a production setting. You 
can greatly mitigate certain risks associated with other migration methods 
because your current source environment is “untouched” when using manual 
migration. 

If you have a situation where you do not want to migrate all your applications in a 
single downtime window to the target version, you should consider the manual 
approach. This approach provides support for two parallel environments, the 
source and the target, and supports selective or phased deployment of the 
migrated applications to the target environment. In contrast, the runtime 
migration method migrates all applications from the source environment to the 
target environment. 

4.1.1 Benefits 

The benefits of manual migration include: 

► This pattern offers a much easier method for version rollback, should this 
become necessary during or after the migration. Because the previous 
version is completely unmodified, including the databases, system 
configuration, and applications, it can be restored relatively easily. 

► The target production environment can be configured differently than the 
source production environment because the configuration is not automatically 
migrated from the source to the target. 

► If you have only non-persistent applications, then this method can be simpler 
than performing the version-to-version migration. 
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► It is easier to modify the WebSphere Process Server ND topology in this 
case, because there is no relationship between the new and existing 
environments. For example, you can use different hardware, add clusters or 
custom nodes, or redistribute applications among the runtime targets in the 
Version 7.0 environment without producing any detrimental impact on the 
pre-migration topology. 

► There is no dependency on the migration tools. 

► Parallel production environment is supported: 

- Selective application migration can be performed. 

- No downtime is required. 

► You have the ability to perform extensive testing before migrating to the 
production environment, but usually regression testing is enough. 


4.1.2 Costs 


The costs of manual migration include: 

► Existing data is not moved; new database tables are created. 

► New features are not enabled automatically and are sometimes unavailable 
without migrating the application artifacts using artifact migration. 

► Manual (scripted) deployment of applications is required. 

► Updates to client applications might be required. 

► Hardware and software licenses might need to be evaluated for any additional 
licenses required when running in parallel. 


4.1.3 Risks 


There are also certain risks that come with a manual migration: 

► Existing user applications should continue to execute in the new runtime at 
the same level of function they had in the old runtime. In some cases, 
however, there might be a change in the code that the application depends 
on, such as a JDK change, which might have a negative impact on the 
unchanged application. 

► The migration process relies entirely on the user to maintain the integrity and 
viability of the WebSphere environment during the upgrade to the new 
version. The user must ensure that the new topology includes all of the 
functionality and configuration settings established in the existing 
environment. The user is responsible for profile and cluster creation, BPC 
configuration, system configuration, and application reinstall. 
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► This process is not feasible for systems with applications that maintain active 
data, such as long-running process instances. There are no pragmatic means 
of transferring existing data from the pre-migration topology to the Version 7.0 
topology. In other words, all active BPC long-running processes or human 
tasks will be lost after activity resumes on the Version 7.0 environment. In 
order to complete these processes, the data must be processed on the 
pre-migration topology. 

► Long running process instances and failed events in the source environment 
are not moved to the target environment with the redeployment of 
applications. Consider running both environments in parallel so that instances 
in the pre-migration environment finish their work (dry out) and new instances 
are started in the Version 7.0 environment. 

Alternatively, consider the runtime method of migration, as it replicates the 
source environment as is on the target environment, including in-flight long 
running processes and failed events. 


4.2 Manual migration steps 

Although many users consider this a form of migration, there is technically no 
migration here. The environment is simply recreated with new versions of the 
BPM products. After applications are reinstalled on the Version 7.0 topology, the 
pre-migration system is brought down and traffic resumes on the new system. 
The entire topology is recreated from top to bottom, which means that the new 
environment can have a different ND configuration from the previous topology if 
desired. New databases are created, and none of the existing data from the 
pre-migration topology is retained in the new Version 7.0 topology. Because all 
applications are reinstalled and no existing data is retained, any long-running 
process instances or applications running with persistent data will be 
permanently lost. Likewise, any configuration data from the pre-migration 
topology will need to be reconfigured by the user. 

The new version of the product is installed as is done with a traditional migration. 
However, instead of using migration scripts to migrate the existing profiles and 
configuration parameters from the pre-migration topology, the new, parallel 
environment is created by the user. The node agents, clusters, and system 
parameters are entirely reconfigured by the user. The pre-migration environment 
does not need to be shut down while the new environment is created, because 
there is no correlation between the two environments. The applications are 
redeployed and reinstalled on the new environment. 
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You should perform the following, general actions: 

► Install the new hardware, operating systems, and product versions. 

See “System analysis” on page 40 for a list of Web sites that contain the 
system requirements for the BPM products. 

► Configure your desired parallel production environment. 

Your target production environment is completely independent of your current 
source environment in this scenario. As a result, you might want to configure 
a new production topology based on new requirements. Refer to the following 
book for further examination of the options for WebSphere Process Server 
V7.0 production topologies: 

- WebSphere Business Process Management V7 Production Topologies, 
SG24-7854 

- z/OS: WebSphere Business Process Management V7 Production 
Topologies, SG24-7831 

► Manually deploy applications from the source environment to the target 
production environments. 

Re-deploy application binaries as is. With the manual migration option, you do 
not have to re-architect your current applications; however, be aware that this 
might mean that your applications will not make use of any added features 
and functions in WebSphere Process Server V7.0. (Consider the artifact 
migration option otherwise.) 

► Optional: Run both environments in parallel so business process instances 
and human tasks instances that are in progress finish in the source 
environment and new instances start in the target environment 

The following sections in this book can provide information that you will find 
useful in a manual migration: 

► “Migration road map” on page 39 

► “Post migration” on page 45 

► “Release-specific information” on page 47 
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Artifact migration 


With artifact migration, applications are imported into the development 
environment and migrated by the development tools before deployment to the 
Version 7.0 target runtime environment. This enables the applications to exploit 
the new capabilities offered by Version 7.0. The necessity of this migration 
procedure depends on your migration strategy and your use of adapters. When 
using artifact migration, a new Version 7.0 runtime environment is set up and run 
in parallel with the previous version. As the artifacts are migrated, they are 
deployed to the target environment. 

Artifact migration can also be combined with runtime migration or manual 
migration for a hybrid approach. The runtime or manual migration can be 
performed, resulting in a new Version 7.0 target environment. Then artifact 
migration can be used to update some or all of the applications. The concepts in 
this chapter will apply to any migration approach that includes application 
migration to Version 7.0. 

This chapter provides an overview of considerations when using artifact 
migration. It also describes methods and procedures for using WebSphere 
products to migrate applications and the associated tools to use. 

In addition, this chapter shows the migration of a sample application that was 
developed in WebSphere Integration Developer V6.1 .2 and will be migrated to 
Version 7.0. 
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5.1 General artifact migration considerations 


Artifact migration provides several benefits: 

► It allows you to maintain 1 00% availability of all the applications in the 
production systems. 

► It provides you the opportunity to use the new features in Version 7.0 and to 
perform extensive testing before using the applications in the new 
environment. 

► It allows you to select the applications to be migrated. Not all applications 
must be migrated or enhanced with new features. 

► Artifact migration is not dependent on runtime migration tooling. 

Note that even with a successful runtime migration, artifact migration will be 

necessary in the future as you apply changes to existing applications that were 

developed with a previous version of the development tools. 


5.1.1 Development tools 

Use the following development tools for migrating applications and for future 
design and development. Information about these tools can be found in their 
respective Information Center: 

► IBM WebSphere Integration Developer V7.0, which can be found at the 
following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/index. jsp 
?topi c=/com. i bm. wbi t . hel p .mai nwel come . doc/topi cs/wel come.html 

► IBM WebSphere Dynamic Process Edition Tool and Testing Pack, which can 
be found at the following address: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/index. jsp 
?topic=/com.ibm.wdpe.instal 1 .tool .doc/wdpe_i ntro/concept/cl ient_intr 
o.html 


5.1.2 Deprecated features 

This section briefly points to the Information Center page where all features that 
are deprecated in Version 7.0 are listed: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps.doc/doc/gmig_deprecationl ist.html 
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5.2 Migrating WebSphere Business Modeler models 

This section discusses the migration of WebSphere Business Modeler artifacts 

from previous releases to Version 7.0. 

5.2.1 Migrating models 

Projects that were created with previous versions of IBM WebSphere Business 

Modeler (Version 6.0.x, Version 6.1.x, and Version 6.2.x) can be migrated to 

WebSphere Business Modeler V7.0. 

To migrate an exported version (*.mar) from Version 6.0.x, Version 6.1 .x, or 

Version 6.2.x, perform the following steps: 

1 . Right-click anywhere in the Project Tree view of WebSphere Business 
Modeler. 

2. Select Import from the context menu. The Import wizard opens. 

3. Select WebSphere Business Modeler import under WebSphere Business 
Modeler. 

4. Click Next. The Select type window opens. 

5. Select the WebSphere Business Modeler project that has to be migrated (it 
will have either a .mar or .zip extension). 

6. Click Next. The Import options window opens. 

7. Click Browse. The Browse For Folder window opens. 

8. Navigate to the folder containing the .mar file that should be imported, select 
the folder, and click OK. 

9. In the Files list, select the .mar file containing the project that you want to 
migrate. 

10. Optional: If you do not want to import the simulation snapshots from the 
earlier version of the project, clear the Include simulation snapshots option. 
Choosing not to import your simulation snapshots significantly increases the 
migration speed. 

1 1 .After specifying the import options, click Finish. The import process begins. 

12. When the import completes, a window opens with the results. If any errors or 
warnings occurred during the import process, click Details. To save the error 
log to a text file, click Save Details. Click OK. 

1 3. If migrations errors occurred during the migration process, use the Errors view 
to validate your process models. 

14. Fix any errors that you find. The migration process is now complete. 
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Repeat this process for each .mar project file that you want to import. 


5.2.2 Migrating a team repository 

WebSphere Business Modeler V7.0 does not support the coexistence of model 
elements that are created using different versions of WebSphere Business 
Modeler. Projects that are shared in a team repository must be of the same 
version as that of WebSphere Business Modeler. So when you use WebSphere 
Business Modeler V7.0 to check out Version 5 or earlier projects from your 
version control system, such as CVS, WebSphere Business Modeler 
automatically migrates those projects to the current version. As a result, earlier 
versions of WebSphere Business Modeler can no longer use a project that is 
shared by a team repository after the project is migrated and committed to the 
repository. 

WebSphere Business Modeler V7.0.2 provides continuity from earlier product 
versions and ensures that connections stay intact upon migration, with a built-in 
procedure to perform a smooth transition of your shared project to a new version 
of WebSphere Business Modeler. 

Details about sharing projects of an earlier version with a new version of 
WebSphere Business Modeler can be found at the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s .model er . basi c . i nst .doc/mi grating/mi gratev6reposi tory . html 


5.2.3 Migrating a workspace 

IBM WebSphere Business Modeler V7.0 automatically migrates a workspace 
that contains projects created in an earlier version when it accesses the 
workspace the first time. It also creates a backup of the original workspace, 
which can be accessed by the previous versions. 

In addition to the restriction that the new migrated workspace can only be 
accessed with WebSphere Business Modeler V7.0, any project that is shared in 
a team repository will have a broken connection to the established repository. 

To migrate an existing project in the current workspace, complete the following 
steps: 

1 . Start the WebSphere Business Modeler Version 7.0 development 
environment. This could be a stand-alone WebSphere Business Modeler 
application, an integrated view in WebSphere Integration Developer, or one of 
the supported Rational® products. 

2. Specify the workspace to be migrated. 
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3. When prompted to specify a backup location for the workspace, make sure 
that this location has enough space to store the backup copy, otherwise the 
migration will fail (in which case, the original workspace is not affected). 

4. Optional: You can save space by selecting the Backup as compressed file 
option. However, if any of the paths in the workspace contain non-English 
characters, do not use this option. 

5. Click OK. After a automatic restart of the application, it accesses the migrated 
workspace and opens a window that lists successful and not successful 
migrated projects with corresponding messages for any problems. 

6. Use the Error view to ensure that no errors were generated in your migrated 
models. If any errors appear, correct them. 

Repeat these steps for each workspace you want to migrate. 

For more information concerning WebSphere Business Modeler migration, go to 
the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/index.jsp7to 
pi c=/com.ibm.btools. model er.basic.inst. doc/mi grating/migratev6project.h 
tml 


5.3 Migrating WebSphere Process Server applications 

The migration of a previous version of WebSphere Integration Developer to 
Version 7.0 is mostly automatic, but might require additional configuration within 
the migration procedure. This section contains the steps to perform an artifact 
migration as well as some of the considerations a developer has to keep in mind. 

5.3.1 Artifact migration 

The term artifact migration describes the process of migrating a project that was 
created with an older version of WebSphere Integration Developer. The steps for 
migration include the export of the project from the previous version of 
WebSphere Integration Developer as an integration module and the import of this 
integration module into WebSphere Integration Developer V7.0. 
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In our example, we used the WebSphere Integration Developer V6.1.2 with Fix 
Pack 005 to export the integration module. If you export the integration module 
with another version, you might see slight differences. You can see how to export 
the integration module with the following Information Center links: 

► Version 6.0.2: 

https : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/v6rxmx/topi c/com. 
ibm.etool s.j2eeapp. doc/topi cs/t jsharingexport.html 

► Version 6.1 .0: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/v6rlmx/topi c/com. i 
bm. wbit. 610. hel p. runtime. doc/topi cs/t intrchg.html 

► Version 6.2: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6r2mx/topi c/com. i 
bm. wbit. 620. hel p. runtime. doc/topi cs/t intrchg.html 

Export the project from the source version 

Perform these steps to export the projects from WebSphere Integration 
Developer V6.1.2: 

1 . In WebSphere Integration Developer V6.1 .2, export the artifacts as integration 
module files by selecting File -» Export from the menu. In the next window, 
select Business Integration -> Integration module, as shown in Figure 5-1 . 



Figure 5-1 Export an integration module 
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2. Click Next in the Integration Module Export window and select the modules or 
component to export. Under this section, select the Project interchange for 
sharing modules between workspaces option and click Next. 



Figure 5-2 Export Integration Module: Select modules 


3. In the next window, shown in Figure 5-3, select the destination to store the 
Project Interchange and select the Include dependent projects from 
workspace option. Click Finish. 



Figure 5-3 Export Interaction Module: Select location 
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Import the projects into Version 7.0 

Perform the following steps to import the Project Interchange file into your new 
workspace in Version 7.0: 

1 . Open WebSphere Integration Developer V7.0 and select File -» Import from 
the Main menu. Expand Other and select Project Interchange, as shown in 
Figure 5-4. 



Figure 5-4 Import the Project Interchange file into Version 7.0: Select Import 
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2. In the next window, shown in Figure 5-5, browse to your Project Interchange 
file and select it. Click Select All and then click Finish. 



From zip file: | C:\12-04-2010_PIJTSQ.zip v] | Browse... | 

Project location root: C:\Documents and 5ettings\weij\I | Browse... | 


0 fe3lTS0_lib_vl 
0 t3lTSO_vl 


[select ftll | [ Deselect ftll | Sell 


© [ < Back ] Next : [ Finish ] [ Cancel | 

Figure 5-5 Import the Project Interchange file into Version 7.0: Select the Project 
Interchange file from the file system 


3. A new window for migrating the imported projects will appear (Figure 5-6). 
Click Next. 



Figure 5-6 Workspace Migration Wizard: Introduction 
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4. In the next window, shown in Figure 5-7, you need to select the projects you 
want to migrate. Make sure you select all the referenced libraries and projects 
and click Next. 



Figure 5-7 Workspace Migration Wizard: Select projects 

5. A warning might show you the files that may be modified by the migration, as 
shown in Figure 5-8. Click Next. 



Figure 5-8 Workspace Migration Wizard: Note changes to resources 
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6. The next window, shown in Figure 5-9, show that the current targeted server 
runtime is not defined in your current workspace. By default, it sets the new 
targeted Server Runtime to WebSphere Process Server V7.0. Make sure that 
all of your migrated projects are selected so that you can change them to the 
new server runtime. Click Next. 



Figure 5-9 Workspace Migration Wizard: Select server runtime and projects 

7. Review the messages listed in the next window and make sure that any 
projects referenced by your workspace that are relevant to your application 
can be resolved without any errors. Click Finish. 
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8. If the migration process ends successfully, you should see the message 
shown in Figure 5-10. 



Figure 5-10 Workspace Migration Wizard: Successful completion 

9. To see more details regarding the migration steps, you can open the Migration 
Results view from the main menu by selecting Window ->• Show View ->• 
Other and selecting Migration ->• Migration Results. 

5.3.2 Artifact migration considerations 

When migrating artifacts from previous versions, some of the new features and 
improvements in WebSphere Integration Developer V7.0 will affect your 
workspace. This section provides information about the types of errors you might 
see and how they can be resolved. It is divided into two parts: 

► Validation 

► Component specific considerations 

Validation considerations 

Validation errors in the new version often result from improvements and new 
features. These errors were not present in the previous versions and need to be 
resolved manually. These errors will appear in the Problems view and can be 
associated with various components, such as human tasks, business objects, 
and XSLT maps. 

Java validation 

When using the SDO API to create a data object, there is an added Java 
validation in WebSphere Integration Developer. 
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Table 5-1 lists some of these error messages and provides a description. 


Table 5-1 Java validation problems 


Error message in the Problem view 

Description 

A BO with namespace <namespace> 
and name <BO name> cannot be found. 

Business objects are now validated to 
determine if their given name and 
namespace exist. 

Incompatible method argument type. 
The <BO attribute name> field is of type 
<actual attribute type>. 

Based on the attribute type, the getter 
and setter methods are validated to 
determine if they are used correctly. 

The field <BO attribute name> does not 
exist in the Business Object <BO name 
with namespace>. 

The attributes referenced in the getter 
and setter methods are now validated to 
determine if they exist. 


Java validation errors can occur in the following components: 

► Java components 

► Custom mediation primitive in mediation flows 

► Java snippet activities in business processes 

► Custom mappings in business object maps 

In some cases, you can use the Quick Fix option to solve the error. Right-click the 
error or warning, and if the option Quick Fix is not grayed out, you can use it to fix 
the error (see Figure 5-1 1 ). 
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SDO programming tips 

For a few classes that are used in previous versions of WebSphere Integration 
Developer, the package names have changed. For example, in WebSphere 
Integration Developer V6.0, the BOXMLSerializer could be referenced, as shown 
in Example 5-1. 

Example 5- 1 BOXMLSerializer invocation in Version 6. 0 

com. ibm. websphere. bo. BOXMLSerial izer serializer = new 
com. ibm. websphere. bo. impl .BOXMLSerial izerlmpl () ; 


In all versions, these classes must be located with the help of the Service 
Manager, as shown in Example 5-2. 

Example 5-2 BOXMLSerializer invocation in Version 7.0 

com. ibm. websphere. sea. Servi ceManager srvMgr = 
com. ibm. websphere. sea. Servi ceManager. INSTANCE; 

com. ibm. websphere. bo. BOXMLSerial izer serializer = (BOXMLSerializer) 
srvMgr . 1 ocateServi ce (“com/i bm/websphere/bo/BOXMLSeri al i zer”) ; 


In general, it is a best practice to reference classes indirectly by using the Service 
Manager to locate the service. You can find more examples in the Business 
Process management samples and tutorials page (in the SDO Programming 
section) by going to the following address: 
http : //publ ib.boulder.ibm.com/bpcsamp/index.html 

Circular dependencies 

In previous versions of WebSphere Integration Developer, circular dependencies 
of modules or projects might not be marked as an error, but it might be 
recognized in Version 7.0 as an error. To ignore this circular dependency, you can 
change the building preferences by performing the following steps: 

1 . Open the preferences window by selecting Windows -» Preferences and 
expand the Java and Compiler entries. 

2. Click Building and expand the Build path problems section. 
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3. You will find a drop-down menu next to the Circular Dependencies entry. 
Select Warning from the drop-down menu (Figure 5-12). 


▼ Build path problems 

0 Abort build when build path errors occur 
Incomplete build path: 

Circular dependencies: 

Incompatible required binaries: 

Figure 5- 12 Resolve circular dependencies within build path preferences 

In WebSphere Integration Developer V7.0, the Java preferences might not be 
visible from all perspectives. Therefore, open the Java perspective by selecting 
Window ->• Open Perspective ->• Other and clicking Java. Now open the 
preference window again. Although the applications might be running fine, it is 
necessary to check the project dependencies again. 
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Refactoring 

Consider using the refactoring capabilities if you have to change the artifact 
names or namespaces instead of changing them in one place. Otherwise, 
artifacts referencing the changed artifact might encounter problems. Refactoring 
preserves these relationships. You can either right-click the artifact in the 
Business Integration Explorer and select Refactor or Analyze Impact ->• 
Rename (Figure 5-13) or press the Alt+Shift+R keys while in the name box of a 
artifact name or namespace. 



X Delete 



a '-a Import... 
^Export... 

Change Namespace... 


S Refresh 


B IS ITSO_lib_vl 
3 IS ITSO_vl 
SI 2>l Assembly 
S Depender 
S i0 Integrate 
- ; Prune 

a&p 

SI $ Java 
Q 0 Data Typ 
Q TestB 

news 

Cjg Create a Business Graph 
Export as Image. . . 

|ap Generate Documentation. . . 

Validate 

Compare With ► 

Source ► 

k Flows | Co Build Activities □ Properties 

rty 

Properties 

ifact 


a 1© Interfaces Name 

! ® Transformations Namespace 

1 Primary File 


Figure 5-13 Refactoring for artifact name and namespace 


Attention: If you refactor and are using a team repository, do not forget to 
check in all the changes that occur due to the refactoring. 


XPath 

For XPath expressions defined in Version 6.0 and earlier, there was no distinction 
between business object attributes defined as xsd:attribute and those defined as 
xsd:element. If you migrate XPath expressions from Version 6.0, you might see 
the error shown in Example 5-3. 

Example 5-3 Possible XPath error in Version 7.0 

The <attributen_name> schema element was not found in the 
<xpath_expression> XPATH. 


138 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 



Since Version 6.1 , the symbol has been used to define a xsd:attribute, so 
you need to change the XPath expression from /Sampl eBO/sampl eAttri bute to 
/Sampl eB0/@sampl eAttri bute. 

Component specific considerations 

Some components, such as business object maps, the XSLT mapper, and the 
MQ bindings require special consideration during migration. 

Business object maps 

When using substitution groups within business object maps in WebSphere 
Integration Developer V6.1 .2 or later (including Version 7.0), you might get the 
warning shown in Example 5-4 while migrating. 

Example 5-4 Warning message after migration in business object maps 

CWLAT0064W: The <mapping_number> transform includes an inherited type, 
which might produce unwanted side effects when the map runs. 


Although this transformation will still execute even if the inherited type comes in 
as part of the instance document, you should resolve the issue. If you are not 
using substitution groups or the element with the warning is not involved in a 
substitution group, this warning should not concern you. 

XSLT mapper 

A major change in the XSLT mapper for WebSphere Integration Developer V6.1 
makes it necessary to take a closer look when migrating from Version 6.0 to 
Version 7.0. 

When migrating from Version 6.0 to Version 7.0, be aware that the file extension 
for XSLT maps in Version 6.0 was *.xmx. This extension changed in Version 6.1 
to *.map. However, XSLT map files created using Version 6.0 still work in Version 
6.1 and later (including Version 7.0). 

The current Version 7.0 XML map editor supports custom mapping. This enables 
you to reuse custom XSL code, submaps, and in-line maps that were created 
before. If you want to use the performance improvements in the new XSLT map 
architecture or you want to add logic to your current maps, you have to migrate 
the modules using the old format *.xmx with the help of WebSphere Integration 
Developer V7.0. 
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You can use one of the following ways to migrate your old maps: 

1 . The first option for migration is available if you are using XSL Transformations 
in Version 7.0 that were created with WebSphere Integration Developer V6.0. 
You will see a warning in the Properties view indicating that the mapping file is 
an old format (Figure 5-14). Right-click this warning and click Migrate to 
convert the file to the new format. 



Figure 5-14 Properties view of old XSL transformation to migrate 

2. The second option for migrating old maps occurs when loading a mediation 
module or library that was created with a previous version of WebSphere 
Integration Developer into your workspace. The load will create a warning 
message in the Problems view, as shown in Example 5-5: 

Example 5-5 Warning produced during mediation module load 

The <XSLTransformationFileName.xmx> XML map file that is associated 

with the XSLT node <XSLTransformation_Name> is in the old format. 


You can resolve the warning by performing the following steps: 
a. Right-click the warning message and select Quick Fix. 


[*_ Problems 


Show In Alt+Shift+W ► 


62 errors, 23 warnings, 1 other 


Properties Alt+Enter 


Description - 



The XSLTransformationl_req_l.map m. 

ap file matches an e 

® Show Help 

itor. To ensure accuracy, it is re 


Figure 5-15 Selection of Quick Fix option for old XSL transformation formats 


Optional: If you have multiple warning messages regarding old format 
maps, right-click one message and click Similar Problems to see a list of 
maps that also need to be converted. 
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b. After selecting Quick Fix, the first window of the Migrate Old Mapping 
Wizard opens (Figure 5-16). Select migrate old mapping to a new 
format and click Finish. 



Figure 5-16 Selection of problems to fix 
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c. The Migrate Old Mapping to New Format window opens (Figure 5-17). 
Select the migration flow that has to be changed and click OK. 



Figure 5-17 Migration wizard for old XSL transformation 
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d. As soon as the migration is completed, a message appears and shows 
you the result (Figure 5-18). 



Figure 5-18 Success message for migrating old formats into a new one 
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3. The third migration option is to double-click an old map file in the Business 
Integration view. This opens the Mapping Migrator window (Figure 5-19). 
Select all that maps that you want to migrate from the *.xmx file format to the 
*.map file format and click Migrate. 


XSLTransformationl_req_l .xmx A 

Mapping Migrator (WebSphere Integration Developer) 

» Steps 

XSL Transformation primitives now use mapping files in a new *.map format. Mapping files in the old *.xmx format must be migrated to the new *.n 
further changes to the mapping. This migrator allows you to migrate one or more XSL Transformation primitives from the old *.xmx format, to the 


To use the migrator: 

1. (Optional) Use the 'Find All Old Mappings' button to find other old mappings in the workspace. 

2. Seiect and clear primitives to migrate in the table. 

3. (Optional) Select the 'Use existing XSL file for custom mappings. This is only recommended if the XMX mapping file contains nested custom 

4. (Optional) Clear the 'Backup existing xmx and associated xsl files (to *.v60xXMX and *.v60xXSL)' option (not recommended). 

5. Press the 'Migrate' button. 


-■ Migration 
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□ Use existing XSL file for custom mappings. This is only recommended if the XMX mapping file contains nested custom XSL and XPath logic. 
0 Backup existing xmx and associated xsl files (to *.v60xXMX and *.v60xXSL) 


Figure 5-19 Mapping Migrator for migrating the old *.xmx file format into the *.map format 


Note: If you want to shorten the migration time, disable the automatic build in 
the preferences. During the migration, there are many file changes that will 
start frequent automatic builds. After the migration is done, you can enable the 
automatic build in the preferences again. 
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For more updated information regarding XSLT migration, see the Information 
Center at the following addresses: 

► http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i 
bm. wbi t. hel p.medi at ion. doc/topi cs/txsl mi grate.html 

► http: //publ i b . boul der. i bm. com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. i 
bm. wbi t. help. mi gr. doc/topi cs/cwi dcon.html 

MQ bindings 

If you are using applications that have MQ bindings on imports or exports, you 
need to update the binding configuration. This is necessary because the new 
bindings now use an ActivationSpec class in their configuration rather than a 
listener port. 

The update process of the binding configuration includes defining an additional 
activation specification JNDI name in the endpoint configuration of the binding. 
Therefore, this JNDI name must refer to an already existing activation 
specification JMS resource within the environment. 

If the connection factories for the MQ bindings have one of the following custom 
properties, they have to be removed: 

► SENDEXIT 

► RECEXIT 

► SENDEXITINIT 

► RECEXITINIT 

In addition, the destination properties shown in Table 5-2 need to be added. 


Table 5-2 Custom properties for WebSphere MQ queue destinations 


Destination type 

Property name 

Property value 

Property type 

Send destination 

MDWRITE 

YES 

java.lang. String 

MSGBODY 

MQ 

java.lang. String 

Receive destination 

MDREAD 

YES 

java.lang. String 

MSGBODY 

MQ 

java.lang. String 


See the Information Center for more updated information at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/index.jsp7to 
pi c=/com. i bm. websphere. wesb.doc/doc/radm_mi grati ngmqbi ndi ngs . html 
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For more updated information regarding artifact migration, visit the Information 
Center at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wbit.hel p. mi gr. doc/topi cs/cwi dcon.html 


5.3.3 Adapter migration considerations 

Due to the amount of available adapters, this section only covers selected 
adapter migration considerations. You will find all the available adapters and their 
migration considerations within the Information Center. Look for the “Planning for 
adapter implementation” topic in each specific adapter section at the following 
address: 

http : //www-01 . i bm. com/software/i ntegrati on/wbi adapters/1 i brary/i nfocent 
er/i ndex . html #wsa70 

You should also look at the current compatibility matrix of the WebSphere 

Adapters (JCA), which can be found at the following address: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=0&ql=compati bi 1 i ty+matri x : 

&q2=compati bi 1 i ty+matri x+adapters&q3=compati bi 1 i ty+matri x :+Websphere+Bu 

siness+Integration+Adapters+and+WebSphere+Adapters&uid=swg21252626&loc= 

en_US&cs=utf-8&cc=us&l ang=en 

Currently using Version 6.0.2 or earlier 

In general, if you are currently using Version 6.0.2 or earlier and your applications 
are using adapters, then you have to uninstall applications before runtime 
migration and use artifact migration to migrate these applications and their 
adapters manually (see 5.3.1, “Artifact migration” on page 127 and “Migrating 
applications” on page 153 for information about configuring the right adapter). 
This applies to embedded and stand-alone adapters at Version 6.0.2. For 
information about how to change your stand-alone adapter, see “Currently using 
Version 6.1” on page 147. After a successful runtime and artifact migration, you 
can deploy those applications on the migrated environment. 
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Currently using Version 6.1 

If you are currently using Version 6.1 and if any of your applications embed any of 
the WebSphere Adapters (with the exception of SAP), then the adapter interim fix 
must be applied in the environment prior to starting the migration procedure. This 
can be done by performing the following steps: 

1 . Obtain the “Mandatory adapter fix for running 6.1 Adapters on WPS V7.0” for 
the WebSphere Adapter(s) the applications utilize. Use one of the options 
below to obtain the interim fix: 

a. If you are using WebSphere Integration Developer V6.1 .2, download the 
WebSphere Integration Developer interim fix 005. This interim fix can be 
downloaded from the IBM Support page at the following address: 
http: //www-01. i bm.com/support/docview. wss?uid=swg27017302 

After downloading the fix, extract the desired adapter RAR file from the 
WebSphere Integration Developer installation 
directory >/ ResourceAdapters directory and copy it to the environment 
where the current adapter is installed. 

Note: Update your existing WebSphere Integration Developer to the 
new version by using Install Manager. This might also require a new 
version of your current Install Manager, which can be obtained from the 
IBM Support page at the following address: 

http : //www-947 . i bm . com/support/entry/portal /Overvi ew/Software/R 
ati onal /IBM_Instal 1 ation_Manager 

b. If you do not use the WebSphere Integration Developer or are using a 
version other than Version 6.1 .2, contact the IBM Support team and 
request the “Mandatory adapter fix for running 6.1 Adapters on WPS V7.0” 
interim fix. 

You will receive the updated WebSphere Adapter RAR file as part of the 
interim fix. 

Copy it to the machine where the WebSphere Adapter instance has to be 
updated. 

2. To perform the next steps, you have to know if the current WebSphere 
Adapter is embedded in the application or is installed at the node level in the 
runtime environment. Perform the following steps for your particular scenario: 
a. If your current WebSphere Adapter is embedded in the application: 

i. Use the administrative console to select the application and click the 
Update button. 
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ii. Select the Replace or add a single module option (Figure 5-20). In 
the “Specify the path beginning with the installed application archive 
file to the module to be replaced or added.” field, point to the relative 
path where your WebSphere Adapter RAR file is located in your EAR 
file. 



iii. Click Browse on the local file system to select the new RAR file that 
has the required adapter changes. 
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iv. Accept the default values in the remaining steps and click Finish 
(Figure 5-21). This prevents the current configuration from being 
changed. Only the JAR files are updated. 



Figure 5-21 Update application with new adapter 

v. Test your updated application very carefully before applying any other 
changes. 

b. If your current WebSphere Adapter is installed at the node level: 

i. In the administrative console, navigate to Resources Resource 
Adapters ->• Resource adapters. 

ii. Browse the resource adapter on each node and collect the following 
information. 

Make note of all the managed connection factories configured for the 
adapter by clicking J2C connection factories in the Additional 
Properties section. 

Select each connection factory associated with the Resource adapter 
and note all the activation specification instances configured for this 
WebSphere Adapter. To accomplish this task, click J2C activation 
specifications in Additional Properties and select each activation 
specification associated with this resource adapter. 

You need this information about the connection factories and activation 
specifications to create these definitions again after you install the new 
adapter interim fix. 
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iii. In the administrative console, select Resources Resource 
Adapters ->• Resource adapters and select the adapter. Click the 
Delete button to uninstall the adapter from the current node. Do the 
same for every node in which this adapter is installed. 

iv. Install the new version of adapter. See the corresponding Information 
Center page for your adapter. Select Deploying the module -» 
Deploying the module for production ->• Installing the RAR file on 
the relevant page. 

v. Configure the managed connection factories and activation 
specification instances that were associated with the adapter you 
deleted. 

Note: If the dependent applications have a configuration for the 
managed connection factory and activation specification in the 
.import and .export files respectively, you can uninstall and re-install 
the application to recreate the configuration for the managed 
connection factory and activation specification. 

If the application uses a JNDI reference to configure the managed 
connection factory and activation specification, you must either 
manually recreate the instances documented in the steps in this 
section or use the wsadmin scripts described in the IBM 
developerWorks® article found at the following address: 
http://ltsbwass001.sby.ibm.com/cms/developerworks/websphere/ 

1 i brary/techarti cl es/1001_yu/1001_yu . html 

vi. Test your updated application very carefully before applying any other 
changes. 

Currently using Version 6.2 

If you are currently using Version 6.2 and if any of the applications in your 
environment embed any of the WebSphere Adapters (with the exception of the 
WebSphere SAP Adapter), then the adapter interim fix must be applied in the 
environment prior to starting the migration procedure. 

Perform the following steps: 

1 . Obtain the interim fix for the WebSphere Adapter(s) that the applications 
utilize. You can accomplish this task by contacting the IBM Support team and 
requesting the “Mandatory adapter fix for running 6.2 Adapters on WPS V7.0” 
interim fix. You will receive the updated WebSphere Adapter RAR file as part 
of the interim fix. Copy it to the machine where adapter instance has to be 
updated. 
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2. Apply the same steps that are in “Currently using Version 6.1” on page 147. 
Start with step 2 on page 147. 

WebSphere Adapter for SAP 

If you use the WebSphere Adapter for SAP in your applications, you have to 
uninstall these applications prior to the migration. This is required by the runtime 
pre-migration checklist, which you can obtain from the Information Center at the 
following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. websphere. wps.doc/doc/cmig_vtv_premigcheckl ist.html 

The reason for this action is that the updated SAP SAPJCO library is 
incompatible with the prior Java Runtime Environment. The new SAPJCO library 
supports Java Runtime Environment Version 1 .6. This means all applications 
using the prior WebSphere SAP Adapter in the new WebSphere Process Server 
Version 7.0 environment will fail. You have to perform the following steps to use 
the application after migrating the runtime: 

1 . Manually uninstall all applications that use or embed the WebSphere Adapter 
for SAP prior to the runtime migration, which is explained in Chapter 3, 
“Runtime migration” on page 81 . 

2. Optional: If you use the stand-alone WebSphere Adapter for SAP at node 
level, remove the WebSphere Adapter for SAP from your environment prior to 
your runtime migration. This will include all SAP Adapters at all nodes. 

Note: Remember to store all the information about your managed 
connection factory and activation specification instances configured for the 
WebSphere Adapter for SAP. To find this information, click J2C activation 
specifications in the Additional Properties section for the adapter and 
select each connection factory and activation specification associated with 
the adapter. You will need this information again after you install the new 
WebSphere Adapter for SAP in the migrated environment. 

Additionally, you can use the wsadmin scripts to automatically configure 
the managed connection factories and activation specifications, as 
described in the IBM developerWorks article found at the following 
address: 

http : //I tsbwassOOl . sby . i bm. com/cms/devel operworks/websphere/1 i bra 
ry/techarti cl es/1001_yu/1001_yu . html 

3. Update or migrate these applications with WebSphere Integration Developer. 
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4. Optional: If you used stand-alone WebSphere Adapter for SAP prior to your 
migration, manually install the new WebSphere Adapter for SAP Version 7.0 
at your node levels, after successfully migrating the runtime environment. 

5. Redeploy the updated or migrated application on your environment. 

Updating or migrating applications containing or using the 
WebSphere Adapter for SAP 

If you want to use the features of WebSphere Adapter for SAP Version 7.0, you 
have to migrate your applications with the migration wizard in WebSphere 
Integration Developer Version 7.0. If you do not want to use the new features, you 
can simply update your applications with WebSphere Adapter for SAP Version 

7.0. This adapter is fully compatible with Version 6.0.2, Version 6.1 .0, 

Version 6.1 .2, and Version 6.2, and the application will not need any 
modifications other than updating the adapter. This means that if you have an 
application deployed in Version 6.0.2, Version 6.1.2, or Version 6.2, you can use 
WebSphere Integration Developer Version 7.0 to update this application with the 
Version 7.0 adapter and then deploy the EAR File to the Version 7.0 runtime 
environment. 

If you need more information about updating or migrating your current 
application, see the corresponding Information Center topic at the following 
address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wsadapters. jca. sap. doc/env/shared/rsha_mi gracons_jca.html 

If you decide to perform the migration, perform the steps provided by the 
Information Center, which are found at the following address: 
http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wsadapters. jca. sap. doc/env/shared/tsha_perfmi gration.html 

If you are planning to upgrade rather than migrate your project, use the steps 
provided by the Information Center for WebSphere Integration Developer Version 

7.0, which are found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wsadapters. jca. sap. doc/env/shared/tsha_perf upgrade.html 

WebSphere Adapter for JDBC 

This section discusses how to handle applications that use the WebSphere 
Adapter for JDBC. We chose this adapter to discuss because our walkthrough 
scenarios in Part 2, “Examples” on page 1 93 use this adapter, but the 
information here can be used as a guideline for other adapters. 
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Review the requirements for each specific adapter, using the Overview topic in 
the Information Center for each adapter. Use the following page to find the 
appropriate Information Center: 

http: //www-01 . i bm. com/software/i ntegrati on/wbi adapters/1 i brary/i nfocent 
er/i ndex . html #wsa70 

Determine whether you plan to migrate or update the application. In general, you 
should migrate if you want to use the new features and updates of Version 7.0; 
otherwise, you can just update your application. If you are uncertain whether the 
new features and updates for the adapter could affect your existing adapter 
applications, read the Information Center topic found at the following address: 
http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.wsadapters.jca.jdbc.doc/env/shared/rsha_mi gracons_jca.html 

Migrating applications 

If you plan to migrate your applications to use the new features and updates of 
the new WebSphere Adapter Version 7.0, perform the following steps: 

1 . Export the application from your workspace by right-clicking the application 
and selecting Export. In the window that opens, expand Business 
Integration and select Integration Module. 

Note: In our example, we used Version 6.1 .2 with Fix Pack 005 to export 
the Project Interchange file. If you export the Project Interchange file with 
another version, you might see slight differences. You can learn how to 
export the Project Interchange file in your version by referring to the 
following Information Center topics: 

► For 6.0.2, refer to the following address: 

https : // publ i b . boul der . i bm. com/i nfocenter/dmndhel p/v6rxmx/topi c 
/com. i bm. etool s.j2eeapp. doc/topi cs/t jsharingexport.html 

► For 6.1 .0, refer to the following address: 

http: //publ i b. boul der.i bm. com/i nfocenter/dmndhel p/v6rlmx/topi c/ 
com. ibm.wbit. 610. hel p. runtime. doc/topi cs/t intrchg.html 

► For 6.2, refer to the following address: 

http : //publ i b . boul der.i bm. com/i nfocenter/dmndhel p/v6r2mx/topi c/ 
com. ibm.wbit. 620. hel p. runtime. doc/topi cs/t intrchg.html 

2. Open WebSphere Integration Developer Version 7.0 and create a new 
workspace. 

3. Import your Project Interchange file into your workspace. 
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4. Because your Project Interchange file was created with a earlier version of 
WebSphere Integration Developer, the migration wizard will start 
automatically and select the projects within your Project Interchange file to 
migrate. Complete the workspace migration by following the wizard. For more 
information about how to use the migration wizard, refer to the Information 
Center found at the following address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
. i bm.wbi t . hel p .mi gr. doc/topi cs/tmi gsreart . html 

5. Open the Java EE perspective and right-click your adapter project and select 
Migrate connector project (Figure 5-22 on page 155). 


Note: There are also other ways to launch the adapter migration wizard: 

► In the Java EE perspective, right-click the project that contains the 
Import using the adapter and select Migrate adapter artifacts. 

► In the Problem view, right-click a migration-specific message and select 
Quick Fix to correct the problem. 

If the adapter type is not supported or the adapter project has the latest 
version, then these options are not available for selection or the menus are 
disabled. 
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6. In Figure 5-23, you will see four fields. 



Figure 5-23 The Select Projects window 

a. The Source connector field displays the name of your project that you 
want to migrate. If you want to migrate one adapter, select the source 
project from the list. 

If you want to migrate multiple adapters in one module and you want to 
migrate all of them, see the Information Center for the detailed steps to 
perform by going to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/ 
com. ibm.wsadapters.jca.jdbc.doc/env/shared/rsha_mi gracons_jca.htm 
l#mig_mul_adapters 

b. The next field, the Target connector field, shows the name of the adapter 
you want to migrate. If you are working with more than one adapter in your 
project, select the adapter that you want to migrate. 

c. In the Target Version field, select the adapter version to which you want to 
migrate. 
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d. A list of dependent projects are listed in the Dependent artifact project 
area. If you opened the Adapter Migration wizard by migrating a module 
project, you will find only the selected module project in this field. If you 
opened the Adapter Migration wizard by migrating the adapter module, 
you will find all the projects that reference the selected adapter project, 
including the adapter project itself. 


Note: By default, all of the dependent artifact projects are selected. You 
can deselect dependent projects to migrate them at a later time. 
Previously migrated projects, projects with the newest adapter version 
available, and projects containing errors cannot be migrated to the new 
adapter version. For more information about upgrading these projects 
versus migrating them, refer to the Information Center found at the 
following address: 

http : //publ i b.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi 
c/com.ibm.wsadapters. jca.jdbc. doc/env/shared/tsha_perf upgrade. h 
till 


7. Click Next. A warning window opens (Figure 5-24). Click OK. 



Figure 5-24 Adapter Migration Wizard Warning 
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8. In the next window (Figure 5-25), you can review the migration changes that 
will occur in each of the artifacts that will be migrated. You can expand each 
node to see the complete migration changes. 



Figure 5-25 Review Changes within Adapter Migration Wizard 
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9. Click Finish. 


Note: After you migrate the project, it is no longer compatible with previous 
versions of WebSphere Process Server, WebSphere Enterprise Service 
Bus, or WebSphere Integration Developer. 

Before the adapter migration wizard runs the migration process, a backup 
of all projects affected by the migration is created in a temporary folder in 
the workspace. If you decide to cancel the migration before completion or 
the migration process fails for any reason, then the modified projects will be 
deleted and replaced with the projects stored in the temporary folder. 

After a successful adapter migration, all backup files in the temporary 
folder are deleted. 


For more updated information, see the Information Center found at the following 
address: 

http://publib.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m.wsadapters. jca.jdbc.doc/env/shared/tsha_perfmi gration.html 

Updating applications 

If you plan to update the application versus migrating them, perform the following 
steps: 

1 . Follow steps 1 to 4 in “Migrating applications” on page 153 to migrate the 
applications. 

2. Open the Java EE perspective, right-click the adapter project name, and 
select Migrate connector project. 
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3. In the Adapter Migration Wizard window, deselect every dependent artifact 
projects and click Next (Figure 5-26). 



Figure 5-26 Deselect all dependent artifact projects 

4. Click OK in the window where the following message is displayed: 

“The properties that are not supported in the version of the target adapter will 
be removed during the migration.” 
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5. Review the migration changes in the window that opens during the update of 
the adapter project (Figure 5-27). You can expand each node to view more 
change details. Click Finish. 



Figure 5-27 Review all migration changes 

For the latest information about this topic, see the Information Center found at the 
following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m.wsadapters. jca.jdbc.doc/env/shared/tsha_perf upgrade.html 

Other adapters 

You can either use the description of the WebSphere Adapter for JDBC 
migration/update as a basic guide for other adapters or see the equivalent pages 
in the Information Center. 
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The addresses for the respective Information Centers are shown in Table 5-3. 
Table 5-3 Information Center links 


Adapter name 

Information Center link 

WebSphere Adapter for 
Email 

http : //publ i b . boul der . i bm.com/ i nfocenter/dmndhel 
p/V7 . OrOmx/topi c/ com. i bm. wsadapters . j ca . emai 1 . do 
c/env/shared/stsha_mi grate. html 

WebSphere Adapter for 
Flat Files 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel 
p/V7 . OrOmx/ topi c/com. i bm. wsadapters .j ca . f f . doc/e 
nv/shared/stsha_mi grate . html 

WebSphere Adapter for 
FTP 

http : //publ i b . boul der . i bm.com/ i nfocenter/dmndhel 
p/V7 . OrOmx/topi c/ com. i bm. wsadapters .j ca . ftp . doc/ 
env/ shared/ stsha_mi grate . html 

WebSphere Adapter for 
IBM i 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel 
p/V7 . OrOmx/topi c/com. i bm. wsadapters .j ca . i seri es . 
doc/env/shared/stsha_mi gratei sa . html 

WebSphere Adapter for 
JDBC 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel 
p/V7 . OrOmx/ topi c/com. i bm. wsadapters .j ca . j dbc . doc 
/env/shared/st sha_migrate.html 

WebSphere Adapter for JD 
Edwards EnterpriseOne 

http : //publ i b . boul der . i bm.com/ i nfocenter/dmndhel 
p/V7 . OrOmx/topi c/ com. i bm. wsadapters .j ca . j de . doc/ 
env/shared/stsha_mi grate.html 

WebSphere Adapter for 
Oracle E-Business Suite 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel 
p/V7. OrOmx/ topi c/com. ibm. wsadapters. jca.oracleeb 
i z . doc/env/ shared/ stsha_mi grate . html 

WebSphere Adapter for 
PeopleSoft Enterprise 

http : //publ i b . boul der . i bm.com/ i nfocenter/dmndhel 
p/V7 . OrOmx/topi c/com. i bm. wsadapters .j ca . peopl eso 
ft. doc/env/shared/stsha_mi grate. html 

WebSphere Adapter for 
SAP Software 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel 
p/V7.0r0mx/topic/com.ibm.wsadapters.jca.sap.doc/ 
env/ shared/ stsha_mi grate . html 

WebSphere Adapter for 
Siebel Business 
Applications 

http : //publ i b . boul der . i bm.com/ i nfocenter/dmndhel 
p/V7 . OrOmx/topi c/ com. i bm. wsadapters .j ca . s i ebel . d 
oc/env/shared/stsha_mi grate. html 
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5.3.4 Migrating a process instance 


One new feature of WebSphere Dynamic Process Edition Version 7.0 is the 
ability to migrate running process instances to a newer application version. This 
action might get mixed up with the artifact migration by someone who is new to 
this topic. These running process instances are already an artifact of Version 7.0. 
Therefore, you should keep in mind that this feature has nothing to do with 
migrating artifacts from previous WebSphere Integration Developer versions into 
artifacts for WebSphere Dynamic Process Edition Version 7.0. 

For more information about migrating running, old process instances into a newer 
process version and how to set up process migration specifications, see the 
Information Center found at the following address: 

http : //publ i b.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. wbi t . hel p. bpel .doc/topi cs/tversi on . html 


5.4 Migrating WebSphere Business Monitor models 

This section provides information about migrating WebSphere Business Monitor 
models created with a previous version of WebSphere Integration Developer. The 
previous versions include WebSphere Business Monitor V6.02, V6.1 .0, V6.1 .2, 
and V6.2 and WebSphere Business Integration Monitor V4.2.4. 


5.4.1 Migrating WebSphere Business Integration Monitor V4.2.4 
models 


Before migrating a WebSphere Business Integration Monitor model from 
WebSphere Business Integration Monitor V4.2.4, make sure you have at least 
Fix Pack 3 of WebSphere Business Integration Monitor V4.2.4 installed. 

In addition to migrating only WebSphere Business Integration Monitor models, 
you can also migrate process instances, activity instances, and business 
measure values that are associated with each model. For more details, see the 
Information Center found at the following address: 

http: //publ i b.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_424 . html 

The WebSphere Business Monitor V7.0 Migration Wizard is a component in 
WebSphere Integration Developer that allows the user to easily migrate modules 
that were created with previous versions of WebSphere Integration Developer. 
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Before you can use the Migration Wizard, you have to complete the following 

tasks: 

1 . Migrate your Version 4.2.4 FDL model structure to the new structure by using 
the “FDL to monitor model” utility for WebSphere MQ Workflow utility. For 
more information about how to generate a monitor model from an FDL file, 
see the Information Center found at the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm . btool s . hel p .moni tor . dev . doc/mqwf /wmqwf_mm_gen . html 

2. Stop those applications that are emitting events for the models that you plan 
to migrate. 

3. For processes in each FDL model, disable the database auditing 
(AUDIT_TO_DB). 

4. For processes in each FDL model, enable the WebSphere MQ auditing 
(AUDIT_TO_MQ). 


Note: Follow these rules while generating the model for Version 7.0: 

► Do not change the hierarchy of the monitor contexts. 

► Do not remove monitor contexts. 

► Do not modify the generated ID fields for monitor contexts. 


To migrate your Version 4.2.4 models, use the Model Migration panel of the 
migration utility described in the Information Center found at the following 
address: 

http: //publ ib.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. i b 
m . btool s . hel p .moni tor .mi g . doc/mi g/model _mi g . html 


5.4.2 Migrating WebSphere Business Integration Monitor V6.0.2 
models 


When migrating WebSphere Business Integration Monitor from Version 6.0.2 to 
Version 7.0, you have to concentrate on two tasks: migrating models and 
migrating data. This section only covers the migration of the monitor models, 
which involves converting and deploying models. 

A complete migration task list is available in the Information Center found at the 
following address: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com. i b 
m. btool s . hel p .moni tor .mi g . doc/mi g/mi g_602 . html 
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Important: If you are using Version 6.0.1 , you first have to migrate to Version 
6.0.2. 1 with interim fix 5 or later. This also applies to all previous versions to 
Version 6.0.2. 1 interim fix 5. Make sure to update before performing any 
migration tasks. 


In WebSphere Integration Developer Version V7.0 there is a WebSphere 
Business Integration Monitor Model editor that automatically converts 
WebSphere Business Monitor models. After migration to the Version 7.0 format, 
the model can be deployed to WebSphere Business Monitor Version 7.0 with the 
help of the administrative console. Alternatively, you can use a batch file that 
does not require an Eclipse environment. 

For the migration of the WebSphere Business Integration Monitor model, you 
need to have either WebSphere Dynamic Process Edition Tool and Testing Pack 
or WebSphere Integration Developer V7.0, which already has the WebSphere 
Business Integration Monitor development toolkit included. 

Before you migrate your WebSphere Business Integration Monitor model, you 
should have the Adaptive Action Manager data migrated. The Adaptive Action 
Manager is a component in WebSphere Business Monitor V6.0.2. It receives 
situation events emitted by applications, selects appropriate actions based on 
user-defined rules and policies, and invokes one or more actions. For more 
information about the Adaptive Action Manager, go to the following address: 
http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6rxmx/topi c/com. i bm. 
btool s . hel p.moni tor .doc/Doc/tasks/admi ni strati on/am_actionmanager . html 

For information about the migration for the Adaptive Action Manager, go to the 
following address: 

http: //publ i b.boul der. i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p.moni tor .mi g . doc/mi g/acti on_mgr_data_mi grati on . html 

Example migration for Version 6.0.2 

Before migrating the models, you have to perform the following steps: 

1 . Stop all applications that are submitting events that are consumed by your 
WebSphere Business Integration Monitor model. 


Note: Incurring downtime for these applications is done to ensure that no 
events are missed during migration and that no duplication processing of 
events occurs. 
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2. Configure each Version 6.0.2 model in the administrative console of Version 
6.0.2 so that it does not create more instances: 

a. Select Applications -> Monitor Models. Choose your model and click 
the version value next to your model (Figure 5-28). 



Figure 5-28 WebSphere Business Integration Monitor Model migration: Select the 
Version value of your model 

b. In the next window, look at the Version Properties section and click 

Change CEI distribution mode (Figure 5-29). 



Figure 5-29 WebSphere Business Integration Monitor Model migration: Select 
Change CEI distribution mode 
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c. In the next window, select the Active (monitor model queue-based, no 
new instances) option and click OK (Figure 5-30). 


Note: Migration from WebSphere Business Monitor V6.0.2 to V7.0 requires 
artifact and data migration. Changing the monitor model state will ensure 
that no new instances are created in the Version 6.0.2 environment. New 
instances will be created only in the new Version 7.0 system. 



Figure 5-30 WebSphere Business Integration Monitor Models: Monitor to Active with 
no creation of new MC instances 

d. Save your changes to the master repository. 
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Perform the following steps to migrate a WebSphere Business Integration 
Monitor model from WebSphere Business Monitor Version 6.0.2 to Version 7.0: 

1 . Create a Project Interchange file containing your WebSphere Business 
Integration Monitor model in Version 6.0.2. Do not forget to include all the 
referenced projects and libraries (Figure 5-31). 

(Beginning with Version 6.1 .2, you can click the Select Referenced option to 
automatically include your referenced sources.) 



Figure 5-31 Export WebSphere Business Integration Monitor model Version 6.0.2 as 
a Project Interchange file 

2. Open your WebSphere Integration Developer Version 7.0 and create a new 
workspace. 
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3. Open the Business Monitoring perspective (Figure 5-32). 



Figure 5-32 Open Business Monitoring Perspective in Version 7.0 

4. Right-click in the Project Explorer view and select Import. 

5. Expand the Other folder and select Project Interchange (Figure 5-33). Click 

Next. 



Figure 5-33 Select Project Interchange as Import 
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6. Browse to your Version 6.0.2 Project Interchange file and select it. Select your 
WebSphere Business Integration Monitor model and all the referenced 
projects and libraries (Figure 5-34). Click Finish. 


it- Import Project Interchange Contents 



Figure 5-34 Import your WebSphere Business Integration Monitor model Project 
Interchange file 
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7. When the import is finished, the Workspace Migration Wizard automatically 
will start. Click Next (Figure 5-35). 



Figure 5-35 Workspace Migration wizard 


8. Select all the projects and referenced projects to be migrated. Click Next 
(Figure 5-36). 



Figure 5-36 Select projects to migrate 
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9. Note the resources that might be modified by the migration and click Next 
(Figure 5-37). 



Figure 5-37 Migration note about which resources might be modified 
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10. Select the projects that target the new runtime environment and click Next 
(Figure 5-38). 



Figure 5-38 Select projects targeting the new runtime environment 
1 1 .Click Finish (Figure 5-39). 



Complete Migration Startup 

Ready to begin migration 


■ Inlxl 


Select the Finish button to begin migration of the projects you have selected. 


< Back | Next > | j^^Finish^J Cancel | 


Figure 5-39 Begin migration 
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12. Your migration should finish with a success message (Figure 5-40). 



Figure 5-40 Migration success message 


13. For a detailed view of the migration steps and errors, open the Migration 
Result view by selecting the Migration Results tab (Figure 5-41). 



Now, you can deploy the migrated model by performing the following steps: 

1 . In the Project Explorer view, expand the WebSphere Business Integration 
Monitor model project and right-click the WebSphere Business Integration 
Monitor model. Select Generate Monitor J2EE Projects, which will generate 
application, moderator and model logic in your current environment. 
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2. To build a deployable EAR file for the Monitor Server, right-click the 
WebSphere Business Integration Monitor application project and select 
Export -> EAR file (Figure 5-42). 



Figure 5-42 Exporting an EAR file for server deployment 


3. Deploy the new EAR file using the WebSphere Business Monitor V7.0 
administrative console. Once deployed, you can use the administrative 
console to set your model to one the following states: 

- Active (monitor model queue bypass) 

- Active (monitor model queue-based) 

- Inactive 

4. Restart your event-emitting applications. If any old instances resume and 
send events to the new model, how your new model will respond to this event 
depends on its configuration. If your model is configured to generate an error 
for an event for which no instance is found, this event is sent to the error 
queue. This error event can be deleted in the WebSphere Business 
Integration Monitor administrative console. 


5.4.3 Migrating WebSphere Business Integration Monitor V6.1.0, 
V6.1.2, and V6.2 models 

WebSphere Business Integration Monitor models generated for WebSphere 
Business Monitor V6.1 .0 or higher can be deployed on Version 7.0 in the 
WebSphere Business Monitor Runtime Migration. If you are performing a manual 
migration, you can simply deploy your modules on WebSphere Monitor Server 
V7.0. 
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For more information about how to deploy WebSphere Business Integration 
Monitor Models to the WebSphere Business Integration Monitor Server, refer to 
the Information Center found at the following address: 

http://publib.boul der.i bm.com/ i nfocenter/dmndhel p/V7 .OrOmx/topi c/com. ib 
m. btool s . hel p .moni tor . dev . doc/mme/devel opi ngmoni tormodel s . html 


5.5 Migrating Business Space widgets 

This section briefly describes how to migrate Business Space widgets from 
Version 6.2 to Version 7.0. This section assumes that you have experience 
developing widgets for Business Space. For more documentation about 
developing widgets for Business Space V6.2, go to the following address: 
http : //publ i b . boul der.i bm. com/i nfocenter/dmndhel p/v6r2mx/topi c/com. i bm. 
bspace.620.hel p.devt. doc/doc/concepts/busi ness_space_devt/coverview.htm 


Widgets that have been developed in Version 6.2 or earlier must be migrated into 
widgets for Version 7.0, or they will not work in Version 7.0. 

To migrate the widgets, perform the following steps: 

1 . Migrate the runtime profile that has the custom widgets. This is required 
because widgets use the business space environment. A migrated business 
space is a prerequisite for widget migration. 

2. Uninstall the custom widget EAR from the cluster. 

3. If the custom widgets use Dojo, upgrade the Dojo installation in your runtime 
environment to Dojo VI .3.2. For more information about how to upgrade Dojo, 
go to the following address: 

http://www.dojotookit.org 

This upgrade is important because in Business Space V7.0, the IBM Dojo 
Toolkit is based on Dojo ToolkitVI .3.2. However, this bundled version will be 
updated as needed over time. This could include entire new Dojo versions, as 
well as specific defect fixes. Compatibility of future Dojo versions is defined by 
the Dojo project. 

4. If your widget needs to support multiple languages, add localized event 
descriptions as an update to the widget XML in your development tool. 
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To add localized event descriptions, add one <iw:alt> element for each 
language. The <iw:alt> element is a new child of the <iw:Description> 
element: 

<iw:eventDescription 

t i t 1 e= " { title }" 
lang=" en " 

<iw:alt 

description="{ description }" 
t i t 1 e= " { title }" 
lang="{ languages }" /> 

</iw:eventDescription> 

5. To package the widget for deployment, perform the following steps: 

a. Create an ear directory and copy the EAR files containing the migrated 
widget definition files and widget implementation files into it. 

b. Create a catal og directory and copy the catalog XML (widget registration) 
files into it. 

c. Create a endpoi nts directory and copy the endpoint registration files into it 
(if they exist). 

d. Optional: Create a tempi ates directory and copy the template ZIP files into 
it (if they exist). The template definitions in the ZIP files must be in the 
Lotus Mashups template format. 

e. Create a hel p directory and copy the help plug-ins into it (if they exist). 

f. Compress the ear, catal og, endpoi nts, tempi ates, and hel p directories. 
Check that the structure of the compressed file contains the following 
items: 

• ear\widgets_name.ear (one or more EAR files) 

• catal og\catalog_name. xml 

• endpoints\*.xml 

• templates\*.zip 

• help\eclipse\plugins\* 

6. At a command prompt, change directories to profi le_root/ bi n. 

7. Enterwsadmin.bat -conntype NONE and then enter the appropriate command: 
- For migrating the widgets into a non-clustered environment, run the 

following command: 

$AdminTask i nstal 1 BusinessSpaceWidgets {-nodeName node 
-serverName server -widgets fullpath} 
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- For migrating the widgets into a clustered environment, run the following 
command: 

$AdminTask i nstal 1 BusinessSpaceWidgets {-cl usterName cluster 
-widgets fullpath } 

In each case, fullpath is the name and location of the ZIP file or parent folder 
you created. 

For more information about the install BusinessSpaceWidgets command, go 

to the Information Center found at the following address: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 

. ibm. websphere. wbpm.bspace.config.doc/doc/rref_i nstal 1 businessspace. 

html 

8. Enter Exit. 

9. Restart the server or cluster. 


5.6 Sample migration 

This section provides a sample migration of an application that was developed in 
WebSphere Integration Developer V6.1 .2 with Fix Pack 005 and is migrated to 
Version 7.0. 


5.6.1 Sample application description 

This section briefly describes the sample application. 

Application 

This application is based on the sample Business Process Execution Language 
(BPEL) applications that are shipped with WebSphere Business Process 
Management V6.1.2 Production Topologies, SG24-7665. You can download 
these applications at the following address: 
ftp : //www. redbooks . i bm.com/redbooks/SG247665/sg247665 .zip 

The altered application is the vehicle loan process of a fictional organization 
called ITSOBank. The goal of this business process is to collect and analyze a 
loan applicant’s information and provide a suitable loan customized to the 
customer. 
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This application consist of the following modules: 

► ITSO_v1 (containing a long running BPEL) 

► ITSO_med_v1 (containing a mediation flow) 

► ITSO_lib_v1 (containing interfaces and complex Business Objects) 

► ITSO_impl_v1 (containing HTTP Exports and SCA Imports) 

► CWYBC_JDBC_v1 (JDBC Adapter module) 

► MM Model 

5.6.2 Features included in the sample application 

This section describes what features of WebSphere Process Server and 
WebSphere Business Monitor the sample application uses. 

Features from WebSphere Process Server 

Our sample application uses the following features: 

► Long running process 

We add a human task called “approvalTask” in the original BPEL. The human 
task was assigned as potential owners to a group called “ITSOApprover”. 
Also, a user interface of Business Space type was generated for this human 
task. 

► Human task escalation 

Our human task in the BPEL contains a escalation logic that fires an 
escalation of Notification Type “Work item” after a certain period of time. This 
work item is assigned to a single user called “ITSOAdmin”. 

► Reusable Service Component Architecture 

All of the Java implementations for business service are exported as web 
services with HTTP binding. They are reusable SCA components. In addition, 
we use SCA invocation between our modules. 

► Business rules 

We use one business rule group with a simple decision table for one rating 
service in the vehicle process. 

► Business Object mapping 

A simple Business Object mapping (BOMap) is added to pass a constant into 
a Business Object field value. 


Chapter 5. Artifact migration 179 



► Mediation flow 

To test the WebSphere Enterprise Service Bus, a mediation flow is added. 
Within this mediation flow, custom mediations (java snippets) and BOMaps 
are being used. The used mediation flow gets an ID value from the main 
process and queries this ID to the database, returning with the ID value. 

► Outbound JDBC adapter 

The mediation flow executes the query and fetches the record through the 
JDBC adapter. A stand-alone JDBC adapter is deployed into the runtime. 

Features from WebSphere Business Monitor 

Our sample application uses the following features: 

► Monitor detail model 

In the monitor detail model, we only created one monitoring context, 12 
inbound events, 12 triggers, 20 metrics, one stopwatch, one counter, and one 
outbound event. In the context, we use string and int metrics to track the 
detailed properties of the loan and customer information. Stopwatches are 
used to track the process duration. Timeout outbound events will be sent out 
when the human task escalation event occurs. 

► Dimensional model 

In the dimensional model, there are four dimensions and four measures. 

► KPI model 

The KPI models hosts both calculation KPI and aggregation KPI. We also 
define two dynamic KPIs on the dashboard using the KPI manager. 

► Visual model 

The monitor model also contains a monitoring context diagram and a KPI 
context diagram with actions on both diagrams. The SVG diagram comes 
from the WebSphere Business Modeler export. In the dashboard, we 
configure the cooperative mode for instances and diagram widgets so that the 
process execution status can be visually shown on the diagram. 

► Tracking key for exporting value 

The tracking key from WebSphere Business Modeler export is set for one 
measure. Those tracking key will be used to export the supervising result from 
WebSphere Business Monitor into WebSphere Business Modeler. 
WebSphere Business Modeler can use these values to do simulation and 
optimization. 
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5.6.3 Export the projects 


As described in 5.3.1, “Artifact migration” on page 127, depending on your 
current version of WebSphere Integration Developer, you might see slight 
differences while exporting your projects. See the Information Center for 
information about your current version (other than Version 6.1 .2): 

► For Version 6.0.2, go to the following address: 

https : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/v6rxmx/topi c/com. 
ibm.etool s.j2eeapp. doc/topi cs/t jsharingexport.html 

► For Version 6.1.0, go to the following address: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6rlmx/topi c/com. i 
bm.wbi t. 610. hel p. runtime. doc/topi cs/t intrchg.html 

► For Version 6.2, go to the following address 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/v6r2mx/topi c/com. i 
bm. wbit. 620. hel p. runtime. doc/topi cs/t intrchg.html 

Perform the following steps to export the projects: 

1 . In WebSphere Integration Developer V6.1 .2, export the artifacts as Project 
Interchange files by selecting File -» Export. 

2. Select Business Integration ->• Integration module, as shown in Figure 5-1 
on page 128. 



Figure 5-43 Export an integration module 
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Click Next. 


3. in the Integration Module Export window, select all modules and libraries for 
export. Then select Project interchange for sharing modules between 
workspaces and click Next (Figure 5-44). 



Figure 5-44 Sample application export selection 
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4. In the next window, select the destination to store the Project Interchange file 
and select Include dependent projects from workspace and click Finish 
(Figure 5-45). 



Figure 5-45 Sample application export description 
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5.6.4 Import the projects into Version 7.0 and migrate them 


The next steps show how to import the Project Interchange file into your new 
workspace in Version 7.0. Perform the following steps: 

1 . Open WebSphere Integration Developer V7.0 and select File -» Import from 
the Main menu. Expand Other and select Project Interchange, as shown in 
Figure 5-4 on page 130. 



Figure 5-46 Sample application: Select Import source 

2. In Figure 5-47 on page 185, browse to the Project Interchange file and select 
it. Select all the projects by clicking Select All and then click Finish. 
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Figure 5-47 Sample application: Import selection 

3. A new window for migrating the imported projects appears after the import of 
the PI is complete (Figure 5-48). Click Next. 



Workspace Migration 

Welcome to workspace migration 



We have detected project or workspace metadata that needs to be 
migrated from a previous version. The following pages will display what 
projects and files will be affected, and you have control over what 
projects should be migrated (The default recommendation is to allow a 
complete migration). If you are migrating a large number of projects, 
this operation could take a while. 

If you choose not to migrate your projects, they will not function 
properly, and error messages may appear in the problems view. We 
strongly recommend closing your projects if you decide not to perform 
migration at this time. When the projects are reopened, you will be 


Q-d |f Next > i| Finish | Cancel | 

Figure 5-48 Sample application: Workspace Migration wizard 


Chapter 5. Artifact migration 185 



4. In Figure 5-49, select the projects to migrate. Make sure you select all the 
referenced libraries and projects and click Next. 



Workspace projects which need migration 

A Referenced project is not in the workspace - 
CWYBCJDBC 



0 t7 CWYBC_JDBC_V 1 
0 £7lTS0_impl_vl 
0 fiflTSOjb.vl 
0 t7lTS0_med_vl 
0 fc7lTS0_vl 

Select All | Deselect All | Select Referenced ;| 


© < Back | Next > | ^^nish^^J Cancel | 


Figure 5-49 Sample application: Migration wizard project selection 

5. A Warning shows the files that might have to be modified by the migration 
(Figure 5-50). Click Next. 



Figure 5-50 Sample application: Migration wizard warning of changed resources 
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6. Figure 5-51 shows that the current targeted server runtime is not defined in 
the current workspace. Make sure that all of the migrated projects are 
selected in order to change them to the new server runtime. Click Next. 



Figure 5-51 Sample application: Migration wizard selecting target server runtime 
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7. Review the messages. In Figure 5-52, there are two messages to review. The 
first message indicates that the referenced JDBC adapter project is not in the 
workspace. We will be installing the new adapter later, so we can ignore this 
message for now. The second message is about a library associated with 
WebSphere Business Services Fabric. The application is not using 
WebSphere Business Services Fabric, so we can safely ignore this message 
as well. Click Finish. 



Figure 5-52 Sample application: Migration wizard messages 

8. Our migration process ends successfully and the message shown in 
Figure 5-53 is displayed. 




Migration validation completed successfully. See the Migration Results view 
for additional information. 


OK 

Figure 5-53 Sample application: Migration wizard success 

Review the migration results (Figure 5-54 on page 189) by selecting Window ->• 
Show View ->• Other and then selecting Migration ->• Migration Results. 
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jfe Problems ftil Server Logs ■!& Servers 1^ Migration Results £3 'v. Progress 

Validating project: ITSO_vl 

Running validator: Facet Consistency (id= FacetConsistency Validator) 
project nature: org.edipse.wst.common.project.facet. core. nature exists=true 
project file: .settings/org.edipse.wst.common. project. facet. core. xml exists=true 
verified that both nature and settings file exist, (both must exist, or neither exist) 
successfully loaded IFacetedProject model object 

Finished running validator: Facet Consistency (id= FacetConsistency Validator) 

Running validator: Component Consistency (id= ComponentConsistency Validator) 
project nature: org. eclipse. wst. common. modulecore.ModuleCoreNature exists=true 
project file: .settings/org.edipse.wst.common. component exists=true 
verified that both nature and settings file exist, (both must exist, or neither exist) 
successfully loaded IVirtualComponent model object 

Finished running validator: Component Consistency (id= ComponentConsistency Validator) 

Running validator: Orphaned J2EE Meta-Data (id= OrphanedJ2EEMetaDataValidator) 

10 back level j2ee meta-data has been found, file: . j2ee does not exist and no back level natures are defined. 

10 back level web meta-data has been found, file: .websettings does not exist and no back level web natures ar 
nished running validator: Orphaned J2EE Meta-Data (id= OrphanedJ2EEMetaDataValidator) 

Running validator: Application Client Consistency (id= AppCIientConsistencyValidator) 

This project is not identified as an Application Client project 

Finished running validator: Application Client Consistency (id= AppCIientConsistencyValidator) 

Running validator: Application Client Forward Consistency (id= AppCIientForwardValidator) 

This project is not identified as a backlevel Application Client project 

Finished running validator: Application Client Forward Consistency (id= AppCIientForwardValidator) 

Running validator: Connector Consistency (id= ConnectorConsistency Validator) 

This project is not identified as a Connector project 

Finished running validator: Connector Consistency (id= ConnectorConsistency Validator) 

Running validator: Connector Forward Consistency (id= ConnectorForwardConsistencyValidator) 

This project is not identified as a backlevel Connector project 

Finished running validator: Connector Forward Consistency (id= ConnectorForwardConsistency Validator) 

Figure 5-54 Sample Application Migration result view 


5.6.5 Migrating WebSphere Adapter for JDBC to Version 7.0 

After migrating all the modules to Version 7.0, only one error is still showing in the 
Problems view (Figure 5-55). 
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To resolve this error, we must migrate the Adapter project. 

Perform the following steps: 

1 . Right-click the CWYBC_JDBC_v1 adapter project and select Migrate 
connector project (Figure 5-56). 


Pm,ects 

New... □ || 

0 £ ITSO_impl_vl 
ITSO_lib_v 1 
S-jg ITSO_med_vl 
IS 13 ITSO_vl 

New ► 

Show In Alt+Shift+W ► 

Hi Copy Ctrl+C 

^ Copy Qualified Name 

C| Paste Ctrl+V 


Figure 5-56 Sample application adapter migration: Select Migrate connector project 


2. In Figure 5-57, select the JDBC Adapter source module name, the new 
WebSphere Adapter name, and its Version. 


1=======^ — , 


Source connector ; Wi T i \ _^j 

T arget connector : | IBM WebSphere Adapter for JDBC 

Migration facilitates you to perform th 
tasks: 

Target version: |7.0.0.0 •’’1 


Dependent artifact projects: 

• Update from the IBM WebSphere Ad 
JDBC for connector project CWYBC , 

| 0 fc^ITSO_med_vl [6.1.0.0JF03] 

version 6.1.0.0JF03 to the IBM Web 
Adapter for JDBC veision 7.O.O.O. 

Select All | Select None | 

ITSO med vl to maintain comoatib 


Figure 5-57 Sample application adapter migration: Select source and target adapter 


3. Click Next. The warning window shown in Figure 5-58 is displayed. Click OK. 



Figure 5-58 Sample application adapter migration: Warning 
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4. In Figure 5-59, review the migration changes that will occur in each of the 
artifacts. Expand each node to see the complete migration changes. 


B CWYBC_JDBC_vl 

B connectorModule/MET A-INF/ra. xml 

Update adapter IBM WebSphere Adapter for JDBC version 6.1.0.0JF03 to IBM WebSphere 
B .classpath 

Add library connectorModule/DBAdapterCore.jar. 

Organize class path entries. 
l|- ITSO_med_vl 
I B .classpath 

Organize class path entries. 

I 61 WPS_ITSOJDBC_IF.import 

Add fault binding for the related operation. 

Rename the resource adapter to IBM WebSphere Adapter for JDBC when the resource adap 
Add connection type property to the managed connection factory. 

Update resource adapter compatibility version to 7.O.O.O. 
i B WPS_ITSO_JDBC JF.wsdl 
1=1 ITSO_lib_vl 

B jdbc/ltsoltsotable.xsd 

Update resource adapter compatibility version to 7.O.O.O. 

B jdbc/ItsoItsotableContainer.xsd 

1 ■■■■ Update resource adapter compatibility version to 7.O.O.O. 

Figure 5-59 Sample application: Review changes within the adapter migration wizard 

5. Click Finish. 

6. Since there are no errors left, the migration is complete (Figure 5-60). 

Task Flows Build Activities Properties Problems S3 ' Server Logs 
0 errors, 30 warnings, 2 o thers 
Description 

S & Warnings (30 items) 

SI i Infos (2 items) 


Figure 5-60 Sample application: Problems view 
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Part 2 


Examples 


In this part, we provide two migration scenarios that illustrate the migration 
process. Both scenarios feature the runtime migration pattern. 


© Copyright IBM Corp. 2010. All rights reserved. 
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6 


Migrating BPM V6.1.2 to 
WebSphere Dynamic 
Process Edition V7.0 


This chapter provides detailed instructions for migrating a Business Process 
Management V6.1 .2 golden topology to WebSphere Dynamic Process Edition 
V7.0 with full downtime. The topology consists of WebSphere Adapter, 
WebSphere Business Monitor, WebSphere Process Server, and Business Space 
on distributed platform systems. The topology is configured over six machines 
and six clusters. 


© Copyright IBM Corp. 2010. All rights reserved. 
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6.1 Source environment topology 


This section describes briefly the source environment topology. 


6.1 .1 Source environment overview 

This scenario uses the topology referred to as the golden topology, which is built 
by using the remote messaging and remote support topology pattern for 
WebSphere Process Server V6.1 .2.3 and WebSphere Business Monitor 
V6.1.2.5. 

The environment to be migrated is a single cell topology with six clusters and a 
remote DB2 server. The clusters are: 

► WPS.Messaging cluster 

The messaging cluster hosts the messaging engine infrastructure in the cells. 
It contains buses for the Common Event Infrastructure (CEI), the Business 
Process Choreographer (BPC), Service Component Architecture (SCA), and 
WebSphere Business Monitor. 

► WPS.Support cluster 

The support cluster hosts the Common Event Infrastructure, the Business 
Rules Manager, the BPC Explorer, and the BPC Observer applications. 

► WPS.AppTarget cluster 

The application target cluster hosts the Business Flow Manager and the 
Human Task Manager applications. 

► WBM. Support cluster 

The monitor support cluster hosts the monitor action services, the data 
movement services, and monitor rest services. 

► WBM.AppTarget cluster 

The monitor application cluster is where monitor models are deployed. The 
applications in this cluster will reorder the events, process the events, and 
emit outbound events. 

► BPM.WebDashboard cluster 

The Web dashboard cluster hosts Business Space and Alphablox. 
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The topology of the BPM V6.1 .2 cell and its elements are shown in Figure 6-1 . 



Figure 6- 1 BPM V6.1.2 topology 
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6.1.2 Software versions 


We use the software shown in Table 6-1 to create the source environment on six 
machines. The operating system is Windows 2003 Standard Edition Service 
Pack 2. 


Table 6-1 Installed software versions 


Product/Component 

Version 

Install directory 

WebSphere Process Server 

Version 6. 1.2.3/ 
32-bit 

C:\wdpe612 

WebSphere Business Monitor 

Version 6. 1.2.5/ 
32-bit 

C:\wdpe612 

Alphablox 

Version 9.5.0.0 
Build 262 

C : \wdpe612\Al phabl ox 

IBM DB2 Universal Database™ 

Version 9.5 / 
32-bit 

C:\IBM\DB295 


6.1.3 Databases 

With regard to the product databases in the source environment: 

► Separate databases are used for different components. 

► The database administrative user ID is db2admin. 

► The user ID for the Windows log in is the same as the database administrative 
user ID. 

► We put the tablespaces for BPEDB, OBSVRDB, MONITOR, and BSPACEDB 
in an separate directory 

The database configuration and notes regarding migration are shown in 
Table 6-2. 


Table 6-2 Database details including owner, database name and schema 


Database 

Schema name 

Table space 
directory 

Is migration 
required 

Comments 

WPRCSDB 

COMMONDB 

C:\DB2\N0DE0000\ 

Yes 

The common 
database. 3 

BPEDB 

BPC 

C:\DBTableSpace 

Yes 

The BPC database 

OBSVRDB 

OBS 

C:\DBTableSpace 

No 

The Business Process 
Observer database. 
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Database 

Schema name 

Table space 
directory 

Is migration 
required 

Comments 

MEDB 

SCASYS 

C:\DB2\N0DE0000\ 

No 

The SCA system 
messaging data store. 3 

MEDB 

SCAAPP 

C:\DB2\N0DE0000\ 

No 

The SCA Application 
messaging data store. 3 

MEDB 

CEIME 

C:\DB2\N0DE0000\ 

No 

The CEI messaging 
data store. 3 

MEDB 

BPCME 

C:\DB2\N0DE0000\ 

No 

The BPC messaging 
data store. 3 

EVENT 

DB2ADMIN 

C:\DB2\N0DE0000\ 

No 

The Event database for 
CEI events. 3 There is no 
specific schema 
associated with this 
database, so it uses the 
database user ID. 

MEDB 

MONME 

C:\DB2\N0DE0000\ 

No 

The WebSphere 
Business Monitor 
messaging data store. 3 

MONITOR 

MONITOR 

C:\DBTableSpace 

Yes 

The WebSphere 
Business Monitor 
database 

MONITOR 

DB2ADMIN 

C:\DBTableSpace 

Yes 

The Alphablox DB2 
repository. There is no 
specific schema 
associated with this 
database, so it uses the 
database user ID 

BSPACEDB 

IBMBUSSP 

C:\DBTableSpace 

Yes 

Business Space 
database. 

WDPEDB 

ITSO 

C:\DB2\N0DE0000\ 

No 

Test application 
database. 3 


a. The table space is in the default directory. 
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6.1.4 Node and host names 


Each machine hosts only one node. Table 6-3 lists all nodes in the cell. 

Alphablox is installed and configured only on the WebSphere Business Monitor 
custom nodes (WBMNodeOI and WBMNode02). The Alphablox installations 
share the same DB2 database repository. 


Table 6-3 Node information 


Node name/ Instance 
name 

Profile name 

Host name 

Comments 

WDPECellManager 

WDPEDmgr 

saw007-sys1 .itso.ral.ibm.com 

Deployment manger node 

DB2 Instance 

N/A 

saw007-sys2.itso.ral.ibm.com 

DB2 database system 

WPSNodeOI 

WPSCustOI 

saw0 1 6-sy si. itso. ral . ibm.com 

The first WebSphere 
Process Server custom 
node 

WPSNode02 

WPSCust02 

saw016-sys2.itso.ral.ibm.com 

The second WebSphere 
Process Server custom 
node 

WBMNodeOI 

WBMCustOI 

saw0 1 6-sy s3 . itso. ral . ibm.com 

The first WebSphere 
Business Monitor custom 
node 

WBMNode02 

WBMCust02 

saw016-sys4.itso.ral.ibm.com 

The second WebSphere 
Business Monitor custom 
node 


6.1.5 Security settings 

The security used in this scenario is outlined in this section: 

► Operating system security 

We use administrator as the user ID when logging on to the Windows 
systems unless otherwise noted. This user has administrative privileges to 
install BPM product binaries and to create the profiles on each machine. 

► WebSphere component security 

Both administrative security and application security are enabled with the 
file-based federated repository. The primary administrative user ID is admin 
and the administrative password is admin. 
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► Business user role 

The business user roles used in this scenario are shown in Table 6-4. 


Table 6-4 User ID used by sample applications 


User/group name 

Password 

User/group role 

Comment 

ITSORequester 

password 

Common WebSphere 
Process Server user. 

The user will start the 
sample BPEL process. 

ITSOAdmin 

password 

Escalation user. 

The user will receive 
escalations. 

ITSOApprover 

N/A 

The group that has the 
authority for approval task. 

The users in this group will 
be the potential owners for 
approvalTask in the 
sample BPEL application. 

ITSOApprover_member01 

password 

The user belongs to the 
ITSOApprover group. 

The user can claim and 
finish approvalTask. 

ITSOApprover_member02 

password 

The user belongs to the 
ITSOApprover group. 

The user can claim and 
finish approvalTask. 

ITSOMonitor 

password 

Common WebSphere 
Business Monitor user. 

The user can view and 
configure the monitor 
dashboard. This role is 
granted by the Business 
Manager role. This role 
has no authority to 
manage KPI. 

admin 

admin 

Super administrator. 

The administrator of the 
whole system. It is the 
process administrator and 
KPI administrator. 


6.1 .6 Product web applications 

This section describes the web applications for the products in our topology: 
► BPC Observer is deployed on WPS.Support target. It can be accessed by 
using these URLs: 

https://saw016-sysl.itso.ral . i bm.com :9444/bpcobserver 
https://saw016-sys2.itso.ral . i bm.com :9444/bpcobserver 
http://saw016-sysl.itso.ral .ibm.com:9081/bpcobserver 
http ://saw016-sys2 . i tso . ral . i bm. com: 9081/bpcobserver 
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The BPC Observer report is shown in Figure 6-2. 



Figure 6-2 BPC observer report 

► The BPC Explorer application is deployed on the WPS.Support cluster. It can 
be accessed by using these URLs: 
https://saw016-sysl.itso.ral . i bm.com :9444/bpc 
https://saw016-sys2.itso.ral . i bm.com :9444/bpc 
http://saw016-sysl.itso.ral .ibm.com:9081/bpc 
http://saw016-sys2.itso.ral .ibm.com:9081/bpc 

► The Business Rules Manager application is deployed on the WPS.Support 
cluster. It can be accessed by using these URLs: 
https://saw016-sysl.itso.ral . i bm.com :9444/br 
https://saw016-sys2.itso.ral . i bm.com :9444/br 
http://saw016-sysl.itso.ral .ibm.com:9081/br 
http://saw016-sys2.itso.ral .ibm.com:9081/br 
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From the Business Rules Manager, we can check and modify the business 
rule used in the sample application (Figure 6-3). 


Address | §£) https://saw016-sysl.itso. ral.ibm.com:9444/br/pages/index.jsp 


Welcome admin | Logout | Search | 

Publish and Revert 


Business Rule Groups 

□ RatingService 
B |3| performRiskRating 
B performRiskRating 


performRiskRating - Decision Table 

Back | Edit | Copy | 


General Information 
Last Published 
Description 


Apr 16, 201 01 4:00 (Local Time) 


Decision Table 


Input.VINLookupStatus.toUpperCaseO ■> + 

"NOT CLEAh 

Input.CreditScore •• 4 

Output.Riskl 

>=720 

"Medium" 

>=580 and <720 

["High" 

[<580 

['High" 


Figure 6-3 Business Rules Manager 


The Business Space Manager application is deployed on 
BPM.WebDashboard cluster. It can be accessed by using these URLs: 
https://saw016-sys3.itso.ral . ibm.com: 9445/Busi nessSpace 
https://saw016-sys4.itso.ral .ibm.com: 9445/Busi nessSpace 
http://saw016-sys3.itso.ral .ibm.com: 9082/Busi nessSpace 
http://saw016-sys4.itso.ral .ibm.com: 9082/Busi nessSpace 
We can access the Alphablox administrative console to manage the data 
sources and cubes on Alphablox. The Alphablox administrative consoles can 
be accessed by using these URLs: 

https : //saw016-sys3 . i tso . ral . i bm. com: 9445/A1 phabl oxAdmi n 
https://saw016-sys4.itso.ral . i bm.com : 9445/A1 phabl oxAdmi n 
http : //saw016-sys3 . i tso . ral . i bm . com : 9082/A1 phabl oxAdmi n 
http : //saw016-sys4 . i tso . ral . i bm . com : 9082/A1 phabl oxAdmi n 
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The data source of Alphablox is shown in Figure 6-4. 


>5 4-] http://saw016-sys4.itso.ral.ibm.com:9082/AlphabbxAdmin/home/admln/datasource 


My Profile Help-* 


APPLICATIONS ADMINISTRATION ASSEMBLY 


General I Groups I Users | Applications 


MONITOR_C 


Edit Data Source "MONITOR" 


- Data 
Source 


Adapter [application Server Data Source 


Data | jdbc/wbm/MonitorDatabase 

Source 

Name 

Default . ■ 

Username i 

Default ........ 

Password 
Use IBM 

Alphablox t — . 

Username |no |v| 



Figure 6-4 Alphablox administrative console 


6.1.7 REST service endpoints 

For each profile where Business Space is deployed, the endpoint XML files of 

each product are located in the following directories: 

pro/iZe_f7ame/BusinessSpace/registryData 

For example, the endpoint locations in our environment are: 

C:\wdpe612\profi les\WBMNode01\BusinessSpace\registryData 
C : \wdpe612\prof i 1 es\WBMNode02\Busi nessSpace\regi stryData 
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After migration, the REST services should be deployed on the same clusters as 
the source environment. The port number in the endpoints should be kept 
unchanged. 

The following examples show the locations of the endpoints: 

► Endpoints in bpcEndpoints. xml are shown in Example 6-1 . 

Example 6- 1 Endpoints in bpcEndpoints.xml 

<tns : url >https : //saw016-sys 1 . i tso. ral . i bm. com: 9443/rest/bpm/htm</tns 
:url> 

<tns : url >https : //saw016-sys 1 . i tso. ral . i bm. com: 9443/rest/bpm/bfm</tns 
:url> 

<tns:url>https://saw016-sys2.itso.ral . ibm.com: 9443/rest/bpm/htm</tns 
:url> 

<tns:url>https://saw016-sys2.itso.ral . ibm.com: 9443/rest/bpm/bfm</tns 
:url> 


► Endpoints in wps Endpoints. xml are shown in Example 6-2. 

Example 6-2 Endpoints in wpsEndpoints.xml 

<tns:url>https://saw016-sysl.itso.ral . ibm.com: 9443/rest/bpm/brul es/v 
l<tns:url> 

<tns:url>https://saw016-sys2.itso.ral .ibm.com: 9443/rest/bpm/brul es/v 
l<tns:url> 


► Endpoints in monitorABXEndpoints.xml are shown in Example 6-3. 

Example 6-3 Endpoints in monitorABXEndpoints.xml 

<tns:url>https://saw016-sys3.itso.ral .ibm.com:9443/rest/</tns:url> 
<tns:url>https://saw016-sys4.itso.ral .ibm.com:9443/rest/</tns:url> 


► Endpoints in monitorEndpoints. xml are shown in Example 6-4. 

Example 6-4 Endpoints in monitorEndpoints.xml 

<tns:url>https://saw016-sys3.itso.ral . ibm.com: 9443/rest/</tns: url > 
<tns:url>https://saw016-sys4.itso.ral . ibm.com: 9443/rest/</tns: url > 
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6.2 Data preparation before migration 

Before migration, we deploy the sample applications to the source environment. 
For more details about the sample application, refer to 5.6.1 , “Sample application 
description” on page 178 and 5.6.2, “Features included in the sample 
application” on page 179. 

6.2.1 Application data environment 

For verification purposes, we perform the following preparation tasks based on 
the sample application: 

► Multiple BPEL template versions are deployed. 

Usually in a production environment, multiple BPEL template versions will be 
deployed and it is important to test the BPEL versioning functionality after 
migration. Here we deploy three BPEL versions of the vehicle loan process in 
the source environment. 

The differences between the versions are: 

- The rating service implementation is changed from a Java implementation 
to a business rule. 

- The potential owner of ApprovalTask is changed from everyone to 
ITSOApprover group. 

- The user interface for ApprovalTask is added. 

- An invocation task and a user interface is added to the process. 

► Multiple monitor model versions are deployed. 

Monitor models can be modified according to business monitoring 
requirement changes or model corrections. We deploy multiple versions of the 
vehicle loan monitor models. 

The differences between versions are: 

- Inbound events in the monitor model are modified according to the BPEL 
process version changes. 

- Escalation count is added. 

- Process failed events and terminated events are added to terminate the 
process. 

- A new measure with a tracking key is added. 
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Test BPEL data is generated. 

Before migration, several long running BPEL instances and human tasks are 
generated. These instances will be left in place, as shown in Figure 6-5. 


Process Instances for Process Templates 

Use this page to work with process instances that belong to specific process templates. 0 

| Compensate Terminate | Delete | Suspend | Resume | Restart | Activities Related Proc 

r 

Process Instance Name 0 

Process Template Name 0 

n 

_PI : 90030128 .823ab49 .S154d5f6 .ecde0005 

New 

Loan Process VI 

r 

_PI: 90030128. 7ca44df.5154d5f6.7c20084 

New 

Loan Process VI 

r 

_PI: 90030128. 7d72968.5154d5f6.7c200c0 

New 

Loan Process VI 

r 

_PI: 90030128. 7da4acd.5154d5f6.7c200fc 

New 

Loan Process VI 

r 

_PI: 90030128. 808ff48.S154d5f6. 7290000 

New 

Loan Process VI 

r 

_PI: 90030128. 813abd3.5154d5f6. 7290045 

New 

Loan Process VI 

r 

_PI: 90030128. 835ad83.5154d5f6.ecde0033 

New 

Loan Process VI 

r 

_PI: 90030128. 8391b23.5154d5f6.ecde006d 

New 

Loan Process VI 

r 

_PI : 90030128 ,8397bc2.5154d5f6 ,ecde009b 

New 

Loan Process VI 

r 

_PI: 90030128. 839ec5e.5154d5f6.ecde00d5 

New 

Loan Process VI 

r 

_PI : 90030128 ,83a523c.5154d5f6 ,ecde0104 

New 

Loan Process VI 

r 

_PI: 90030128. 83b010a.5154d5f6,ecde013e 

New 

Loan Process VI 

r 

_PI: 90030128. 83b6f93.5154d5f6.ecde016c 

New 

Loan Process VI 

r 

_PI: 90030128. 84 ccf06.5154d5f6.ecde01c8 

New 

Loan Process VI 

r 

_PI: 90030128. 84d25bl.5154d5f6.ecde01eb 

New 

Loan Process VI 

r 

_PI: 90030128. 84 d4a8f.5154d5f6.ecde0215 

New 

Loan Process VI 

r 

_PI: 90030128. 84dbec5.5154d5f6.ecde0238 

New 

Loan Process VI 

n 

_PI: 90030128. 84de642.5154d5f6.ecde0261 

New 

Loan Process VI 

r 

_PI: 90030128. 84e2dab.5154d5f6,ecde028a 

New 

Loan Process VI 

r 

_PI: 90030128. 84eacce.5154d5f6.ecde02b4 

New 

Loan Process VI 

r 

_PI : 90030128 ,84f61b7 ,5154d5f6 ,ecde02d7 

New 

Loan Process VI 

r 

_PI: 90030128. 84f86a4.5154d5f6.ecde0300 

New 

Loan Process VI 

r 

_PI: 90030128 ,8500fe8 ,5154d5f6 ,ecde0329 

New 

Loan Process VI 

Items found: 23 Items selected: 0 

Page 1 of 1 | >> | Items pei 


Figure 6-5 BPEL instances in the BPC Explorer 
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► Test monitor model data is generated. 

Just as we have completed and uncompleted instances for each BPEL 
versions, there are also some completed and uncompleted instances for each 
monitor model version, as shown in Figure 6-6. 



► The global human task model is deployed to test the human task widgets. 

We deploy the global human task model and configure the human task 
widgets in Business Space. 

► DMS is enabled for each monitor model. 

In a production environment, data movement services (DMS) is usually 
enabled for performance consideration. We enable DMS for each monitor 
model versions of the sample monitor model. 

► The alert template is configured. 

The alert template is configured using the administrative console. The Action 
service sends out dashboard alerts when the timeout outbound alert is 
emitted by the monitor model. 
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6.2.2 Server environment 


In this section, we list the server configuration settings and the current state of 
the source environment: 

► Common Event Infrastructure event datastore 

Some events are emitted and stored in the EVENT database. We disable the 
Common Event Infrastructure event datastore, because in a production 
environment, the CEI event datastore is often disabled to achieve higher 
performance. 

► Common Event Infrastructure logging 

We configure the CEI logging for both the Business Flow Manager and 
Human Task Manager. As a result, Common Base Events (CBEs) will be sent 
out during BPEL execution. 

► Human Task Manager group work items 

We enable Human Task Manager group work items. 

► JDBC adapter 

A stand-alone JDBC adapter is deployed on each WebSphere Process 
Server custom node and the J2C connection factory is created. 


6.2.3 Business Space environment 

Now we discuss the configuration and preparation for the source Business Space 
configuration: 

► WebSphere Process Server workspace 

This space is created using the Managing My Tasks template. In this space, 
we can start processes, and claim and work on human tasks. The following 
widgets are included: 

- Create Tasks 

- Available Task 

- My Tasks 

- Task Information 

- Human Task Diagram 
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► WebSphere Business Monitor Workspace 

This space is created for Business Monitoring purposes. The following 
widgets are included: 

- Dimensions 

- Reports 

- Diagrams 

- Instances 

- KPIs 

- Export Values 

- Alerts Subscription 

- KPI Manager 

- Human Tasks 

► Dynamic KPI 

A dynamic KPI named Low Risk Percent and Monthly Escalation Number is 
created using the KPI manager. 


6.3 Source environment preparation 

Before migration, you need to check the source environment to make sure that 
the source environment is in a good state and that there are no in-flight events. 


6.3.1 Determine the common database schema 

Determine what schema name is used for the common database. We need to 
modify the database upgrade script during migration if the schema is not the 
default database user ID by performing the following steps: 

1 . Navigate to Resources ->• JDBC -» Data sources. 

2. Click the WBI_DataSource and, under Additional Properties, click Custom 
Properties. 

3. Scroll down the list or properties and check the values for currentSchema and 
cliSchema. If they are blank, this means that the common database schema 
is the default. For DB2, this is the instance owner name. The schema name is 
COMMONDB in our environment (Table 6-2 on page 198). 


210 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 



4. We can now ensure that the common database schema you found is correct 
by listing that tables in the DB2 command-line interface by using the 
commands shown in Example 6-5. 

Example 6-5 List tables command for common database 

db2 connect to WPRCSDB 

db2 list tables for schema COMMONDB 

db2 terminate 


The sample output is shown in Example 6-6. As you can see, the schema is 
COMMONDB. 

Example 6-6 Tables in common database (the output is truncated) 


Table/View 

Schema 

APPTIMESTAMP 

COMMONDB 

BYTESTORE 

COMMONDB 

BYTESTOREOVERFLOW 

COMMONDB 

CUSTPROPERTIES 

COMMONDB 

FAILEDEVENTBOTYPES 

COMMONDB 

FAILEDEVENTDETAIL 

COMMONDB 

FAILEDEVENTMESSAGE 

COMMONDB 

FAILEDEVENTS 

COMMONDB 

MEDIATION_TICKETS 

COMMONDB 

PERSISTENTLOCK 

COMMONDB 

RELN_METADATA_T 

COMMONDB 

SCHEMAVERSIONINFO 

COMMONDB 

WSCH_LMGR 

COMMONDB 

WSCH_LMPR 

COMMONDB 

WSCH TASK 

COMMONDB 

WSCH_TREG 

COMMONDB 

16 record(s) selected. 



6.3.2 Apply the WebSphere Adapter interim fix (if required) 

In our migration source environment, we have IBM WebSphere Adapter for JDBC 
V6.1 .0.4, which is at the required fix level. Refer to 5.3.3, “Adapter migration 
considerations” on page 146 for the mandatory adapter interim fix for the 
Version 6.1 .x and Version 6.2.x adapters. 
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6.3.3 Failed events 


Using the administrative console for WebSphere Process Server in the migration 
source environment, check the failed events by going to the console and 
selecting Integration Applications Failed Event Manager. 

If possible, all existing failed events should be resolved before migration. The 
number of current remaining failed events should be recorded to ensure that 
there are no failed events lost during migration. After migration, the number of 
failed events should be equal to or larger than current number. 

One convenient approach to record failed events is to take a screen capture of all 
the failed events display pages (Figure 6-7). 


Failed Event Manager > Search results 

The failed events result set shows the failed events found from the most recent query. 


Ref. 

•esh | Get all | Sear 

* 1 1 

Resubmit with trace 

_l . Del6te 1 C 

)elete expired evei 

nts | 



Message ID 0 

Type 0 

Src. module $ 

Src. component 0 

Dest. module 0 

Dest. o 

□ 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v2 

NewLoanProcess.vl 

ITSO_impl_vl 

(expo 

n 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v2 

NewLoanProcess_vl 

ITSOJmpl_vl 

(expo 

n 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v3 

NewLoanProcess.vl 

ITSOJmpl_vl 

(expo 

□ 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v4 

NewLoanProcess.vl 

ITSO_impl_vl 

(expo 

r 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v4 

NewLoanProcess.vl 

ITSO_impl_vl 

(expo 

n 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v4 

NewLoanProcess.vl 

ITSOJmpLvl 

(expo 

n 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO_v4 

NewLoanProcess.vl 

ITSOJmpLvl 

(expo 

n 

1B747FE9999D0BD3.. 

invokeAsync 

ITSO.V4 

NewLoanProcess.vl 

ITSO_impl_vl 

(expo 

Total 

8 








Figure 6-7 Failed events 


Note: It is not mandatory to resolve failed events. You can re-submit them 
after migration. However, it is best to migrate a system in a clean state, that is, 
there are no failed events before the migration. 
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6.3.4 Service Integration Bus (SIB) messages 


All SIB queues should be checked for queued messages and dealt with before 
starting the migration. It is a tedious task to check all the queues one by one 
manually. The Service Integration Bus Explorer GUI tool can be used to browse 
queues quickly and easily. The tool can be downloaded from the following 
address: 

http : //www . al phaworks . i bm . com/tech/si bexpl orer/downl oad 

The current depth for queue points in Monitor.WDPECell.Bus is displayed in 
Figure 6-8. Also, check the queue depth for BPC.WDPECell.Bus, 
CommonEventlnfrastructure_Bus, SCA. APPLICATION. WDPECell. Bus, and 
SCA.SYSTEM.WDPECell.Bus. 


e. Z'dr /Ity liiLh^niLhii liuz EZpIUnir 

file Server View Help 

^ MONITOR. WDPECell.Bus 

!i 

Queue Point Name 

Current Depth 

State 

Lj Destinations 
S'fi WPS.Messaging 

S ^ WPS . Messaging .OOO-MONITOR. WDPECell. Bus 


Igi ActionManagerQueueDestination 
M wbm_EomsMM_200806 16210719. . . 

0 

0 

ACTIVE 

ACTIVE 


I@S wbm_EomsMM_200806 16210719... 

0 

ACTIVE 

| Q BB5H5WE1 

O Publication Points 


I®( wbm_EomsMM_20080616210719... 
I®( wbm_NewLoanProcessMM_20100... 

0 

0 

ACTIVE 

ACTIVE 

CD Mediation Points 


Ifigj wbm_NewLoanProcessMM_20 100. . . 

0 

ACTIVE 

D WMQ Client Unks 
CD WMQ Links 

^ SCA.APPLICATION. WDPECell.Bus 

II 

Ilsi wbm_NewloanProcessMM_20 100. . . 
1®! wbm_NewloanProcessMM_20100... 
M wbm_NewloanProcessMM_20100... 

0 

0 

0 

ACTIVE 

ACTIVE 

ACTIVE 

Cj Destinations 
0 S WPS.Messaging 

0 ^ WPS. Messaging. 000-SCA. APPLICATION. WDPE 

] 

I®S wbm_NewLoanProcessMM_20 100. . . 
lii wbm_NewLoanProcessMM_20 100. . . 
I@i wbm_NewLoanProcessMM_20100... 

0 

0 

0 

ACTIVE 

ACTIVE 

ACTIVE 

CD Queue Points 


Ig( wbm_NewLoanProcessMM_20100... 

0 

ACTIVE 

D Publication Points 
CD Mediation Points 

Hi 

M wbm_NewloanProcessMM_20 100. . . 
Is^ wbm_NewLoanProcessMM_20100... 
IjgS wbm_NewLoanProcessMM_20100... 

0 

0 

0 

ACTIVE 

ACTIVE 

ACTIVE 

Ready 





Figure 6-8 Current depth of queue points in MONITOR. WDPECell. Bus 


In our source environment, all the queues have no messages. 

In general, there should be no messages in the queues when the environment is 
shut down for migration. Any messages that are still in the queues should be 
there for a good reason (from an application or business point of view). Any other 
messages should be handled accordingly before starting the migration. 


Chapter 6. Migrating BPM V6.1 .2 to WebSphere Dynamic Process Edition V7.0 213 


6.3.5 Transactions 


All servers must be checked for open or in-doubt transactions. This check must 
be performed in the administrative console for each server. 

Select Servers ->• Application servers -» server_name -> Container 
Settings Container Services -» Transaction Service -> Runtime, and then 
check all the Review links for transactions. There should not be any transactions, 
as shown in Figure 6-9. 


Application servers > WPS. AppTaroet.WPSNode 02.0 > Transaction Service 



updates of data. Transactions are started and ended by applications or the container in which the 
applications are deployed. 



Figure 6-9 Transaction status for WPS.AppTarget. WPSNode02.0 
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6.3.6 Clean up exceptions 


Before migration, the SystemOut.log files of all application servers should be 
checked for any exceptions. You can search for “E” (there is one blank character 
both before and after char E) in the log file to find exceptions. All runtime and 
application exceptions should be handled accordingly (non-fatal exceptions can 
be ignored on a case by case basis). 

6.3.7 Manually copy third-party artifacts 

We do not use third-party artifacts in our migration source environment, so this 
step did not apply. But, if you have third-party artifacts, you need to manually 
copy them to the migrated environment. See 3.4.2, “Runtime migration for 
network deployment with cluster” on page 99 for more information. 

6.3.8 Stop the source environment 

For a full downtime migration, we need to stop the migration source environment 
before starting the migration procedure. 

Stop the clusters one at a time 

First, stop the clusters in the source environment by performing the following 
steps: 

1 . Log into the administrative console on saw007-sys1 .itso.ral.ibm.com. Select 

Servers ->• Clusters. Check BPM.WebDashboard, then click Stop 
(Figure 6-10). 


| New| Delete | Start | Stop | Ripplestart | ImmediateStop | 

BBS® 

Select Name $ 

Status Q 

FI BPM.WebDashboard 

it 

r 

WBM.AppTarqet 


r 

WBM. Support 


r 

WPS.ADDTaraet 


r 

WPS. Messaging 


r 

WPS. Support 


Total 6 


Figure 6-10 Stop clusters 
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2. Check the SystemOut . 1 og files for each member to ensure that the cluster is 
stopped completely. You should see the message shown in Example 6-7. 

Example 6-7 Cluster member stop log message 

[4/16/10 14:23:54:781 EDT] 00000012 ServerCol 1 abo A WSVR0024I: 
Server BPM.WebDashboard.WBMNodeOl.O stopped 


3. Repeat steps 1 on page 215 and 2 to stop these remaining clusters in 
sequence: 

a. WBM.AppTarget 

b. WBM. Support 

c. WPS.AppTarget 

d. WPS.Support 

e. WPS.Messaging 

Stop the node agents 

Next, we stop the node agents by performing the following steps: 

1 . From the administrative console, select System administration ->• Node 
agents, select all the node agents, and click Stop (Figure 6-11). 


| | Stop || Restart | 

Restart all Servers on Node 

i 

Ci JDS 

Select 

Name 0 

Node C 

Version 0 

Status £> 

w 


nodeaqent 

WPSNode02 

Business 

Choreographer 
6.1. 2. 3 
ND 6.1.0.23 
WPS 6. 1.2. 3 

* 

w 


nodeaqent 

WBMNodeOl 

ND 6.1.0.17 
WBM 6. 1.2. 5 

■> 

w 


| nodeaoent 

WPSNodeOl 

Business 

Choreographer 
6.1. 2. 3 
ND 6.1.0.23 
WPS 6. 1.2. 3 

-> 

w 


nodeaqent 

WBMNode02 

ND 6.1.0.17 
WBM 6. 1.2. 5 

* 

Total 

4 




Figure 6- 1 1 Stop node agents 
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You should see messages similar to the ones shown in Figure 6-12. 


0- The node agent on node WPSNode02 was 
stopped successfully 

0 The node agent on node WBMNodeOl was 
stopped successfully 

0 The node agent on node WPSNodeOl was 
stopped successfully 

0 The node agent on node WBMNode02 was 
stopped successfully 


Figure 6-12 Stop node agents message 

Stop the deployment manager 

Stop the deployment manager by performing the following steps: 

1 . Open a command line window on the deployment manager system. 

2. Navigate to the bi n directory for the profile: 

c : \wdpe612\prof i 1 es\WDPEDmgr\bi n di rectory 

3. RunstopManager.bat -username admin -password admin and press Enter to 
stop the deployment manager, as shown in Figure 6-13. 


C:\wdpe612\prof iles\UDPEDmgr\bin>stopManager. bat -username admin -password admin 

fiDMU0116I : Tool information is being logged in file 

C : \wdpe 612 \pro f i le s NUDPEDmgrN logs \dmgr\s t o pSe rue r .log 
flDMU0128 I : Starting tool with the WDPEDmgr profile 
ADMU3100I : Reading configuration for seruer: dmgr 
fiDMU3201I: Seruer stop request issued. Maiting for stop status. 

RDMU4000I : Seruer dmgr stop completed. 

C:\wdpe612\prof iles\WDPEDmgr\bin>_ Z. 


Figure 6-13 Stop deployment manager 


4. Check the deployment manager sysout log 

(c : \wdpe612\prof i 1 es\WDPEDmgr\l ogs\dmgr\SystemOut . 1 og) to ensure that 
the stoppage is complete. You should see the message shown in 
Example 6-8. 

Example 6-8 Deployment manager stop log message 

[4/16/10 14:43:26:515 EDT] 00000010 ServerCol 1 abo A WSVR0024I: 
Server dmgr stopped 
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6.3.9 Back up the source environment 


Before performing the actual migration steps, back up the source environment, 
including the runtime environment and all product databases and user 
databases. Such a backup is critical for the rollback from an migration failure. 

Back up the installation directory of source environment 

Perform the following steps to back up the runtime source environment: 

1 . Log into the deployment manager machine. Use a third-party compression 
tool to compress the installation directory (C:\wdpe612 in our environment) of 
the source environment into a compressed file. 

2. Repeat step 1 for all the other machines in the migration source environment. 
In this case, these are machines saw016-sys1.itso.ral.ibm.com, 
saw016-sys2.itso.ral.ibm.com, saw016-sys3.itso.ral.ibm.com, and 

sawOI 6-sys4.itso.ral.ibm.com. 


Important: If you created the source profile in a separate directory other 
than under the product binary directory, you should back up both the profile 
and binary directories. 


Back up the product and user databases 

When you back up the runtime installation, you must back up the product 
databases and user databases as well. You can accomplish these tasks by 
performing the following steps: 

1 . Log into the machines hosting the product and user databases 
(saw007-sys2 . itso. ral . i bm . com ) . 

2. Select Start ->• Run..., then enter db2cmd to launch the DB2 command-line 
window. 
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3. Execute the commands shown in Example 6-9 to back up the product 

databases. In addition, back up any user databases that you might need in a 
rollback situation. 

Example 6-9 Product databases and user databases backup 

cd c:\dbbackup 

db2 backup database WPRCSDB 

db2 backup database BPEDB 

db2 backup database OBSVRDB 

db2 backup database MEDB 

db2 backup database EVENT 

db2 backup database MONITOR 

db2 backup database BSPACEDB 

db2 backup database WDPEDB 


6.4 Install WebSphere Dynamic Process Edition V7.0 

Before installing WebSphere Dynamic Process Edition V7.0, you need to check 
whether the prerequisites are at the required level. 

6.4.1 Prerequisite checking 

Runtime migration in a network deployment configuration uses the same 
machine for the target and source environment. Review all the hardware and 
software requirements of the machines where the source environment is located 
before installing any WebSphere Dynamic Process Edition V7.0 component. 
Information about determining the software and hardware requirements can be 
found in 3.5, “Runtime migration for specific BPM products” on page 105. 

Hardware requirements 

Determine your current hardware information first. Our machine has an Intel® 
2.66 GHz CPU, as shown in Figure 6-14, which is in the supported scope (Intel 
Pentium® 500 MHz or faster). 


Computer: 

Intel(R) Core(TM)2 Duo CPU 
E6750 @ 2.68GHz 
2.66 GHz, 3.71 GB of RAM 
Physical Address Extension 
Figure 6-14 Hardware information 
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Note: If the current hardware does not meet the requirements, you need to 
upgrade to the required levels before migration. 


Operating system requirements 

Determine the operating system level of the source environment. We are using 
Windows 2003 Server Standard Edition Service Pack 2, as shown in Figure 6-15. 


System: 

Microsoft Windows Server 2003 
Standard Edition 
Service Pack 2 

Figure 6-15 Operation system information 


Note: If your operating system level is lower than what is required, ask your 
system administrator to upgrade it to the required level before migration. 


Database version requirement 

For DB2, we used the db21 evel command to determine the database version, as 
shown in Example 6-10. 

Example 6-10 Database version 

C:\>db21evel 

DB21085I Instance "DB2" uses "32" bits and DB2 code release "SQL09050" 
with level identifier "03010107". 

Informational tokens are "DB2 v9. 5. 0.808", "s071001", "NT3295", and Fix 
Pack "0". 

Product is installed at "C:\IBM\DB295" with DB2 Copy Name "DB2C0PY1" . 


Our database version is in the supported list for WebSphere Dynamic Process 
Edition V7.0. 


Note: If your database version is lower than required by Version 7.0, ask your 
database administrator to upgrade the database. 
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Java SDK in the installation package verification 

Change directories to the 

/JDK/j re . pak/repos i tory/package . java . j re/ j ava/ j re/bi n directory in the 
product installation package directory and verify the Java version. The command 
completes successfully with no errors when the SDK is intact (Example 6-11). 

Example 6- 1 1 Java SDK in the installation package verification 

C:\software\V7 . 0\JDK\ jre . pak\reposi tory\package . java . jre\ java\jre\bi n>j 
ava -version 

java version "1.6.0" 

Java(TM) SE Runtime Environment (build 
pwi3260sr6i fix-2009 1015_01 (SR6+1522 11+155930+156106)) 

IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows Server 2003 x86-32 
jvmwi3260sr6-20091001_43491 (JIT enabled, A0T enabled) 

J9VM - 20091001_043491 
JIT - r9_20090902_1330i fxl 
GC - 20090817_AA) 

JCL - 20091006_01 


Disk space requirements 

Provide adequate disk space for the WebSphere Dynamic Process Edition V7.0 
installation, backup, and application objects. 

The details for the disk space requirements of our environment are shown in 
Table 6-5. 


Table 6-5 Required disk space for migration 


Directory 

Required disk space 

Comment 

C:\backup 

20 GB 

Source and target runtime 
environment backup 
storage on each runtime 
machine 

C:\backup 

5 GB 

Database backup storage 
on database server 

C:\software 

5 GB 

WebSphere Dynamic 
Process Edition V7.0 
installation package 

C : \Mi grati onSnapshot 

600 MB 

Source profile snapshot 
directory storage 
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Directory 

Required disk space 

Comment 

C:\wdpe7 

3.1 GB 

WebSphere Dynamic 
Process Edition V7.0 
installation storage 

C:\Program 

Files\IBM\Instal lation 
Manager 

200 MB 

Installation Manager 
storage 


6.4.2 Software version of the target environment 

WebSphere Dynamic Process Edition V7.0 has one single installation image. 
The software shown in Table 6-6 is used for the target environment in our 
scenario. The IBM Installation Manager is the common tool for installing all 
products included in WebSphere Dynamic Process Edition V7.0. As a result, the 
Installation Manager package is also shipped in the WebSphere Dynamic 
Process Edition V7.0 installation image. 


Table 6-6 Software version of target environment 


Product/Component 

Version 

Install directory 

WebSphere Dynamic 
Process Edition 

Version 7.0/32-bit 

C:\wdpe7 

Installation Manager 

Version 1 .3.3/32-bit 

C:\Program 

Fi 1 es\ I BM\Instal lation 
Manager 


6.4.3 Installing WebSphere Dynamic Process Edition V7.0 

In this section, we describe the detailed steps that you must perform to install 
WebSphere Dynamic Process Edition V7.0. 

Perform the following steps: 

1 . Create a software repository containing the new product code. 

A repository is simply a folder that contains the installation software., so we 
simply uncompress the WebSphere Dynamic Process Edition V7.0 to the 
appropriate locations; in our case, that location is base_dir. 
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Note: By default, after creating the repositories, the Installation Manager is 
configured to connect to the Internet. If the environment does not have an 
Internet connection, the Installation Manager could appear to hang during 
startup. This topic is discussed in the Technote found at the following 
address: 

http: //www-01. ibm.com/support/docview.wss?uid=swg214142 13 


After creating the base repository for your product, if your machine cannot 
access the Internet, edit the following files: 
base_dir/IM/instal 1 .xml 
jbase_c/ir/IM/post-instal 1 .xml 

Remove or comment out the lines, as shown in Example 6-12. 

Example 6- 12 Sample file of install.xml and post-install.xml(The content is truncated) 


<server> 

<repository location='.' temporary='true'/> 

<repository location=' . ./repository/ 1 temporary='true'/> 

<!-- repository 

1 ocati on= ' http : //publ i c . dhe . i bm . com/software/websphere/reposi tori es/ 


</server> 
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2. Install WebSphere Dynamic Process Edition V7.0 on the machine that hosts 
the deployment manager by performing the following steps: 

a. Navigate to your base_dir directory and double-click 1 aunchpad.exe 
(Figure 6-16) to invoke the IBM WebSphere Dynamic Process Edition 
Server V7.0 Launchpad. 


Name - I 

Size | Type 

QcilStom : 


File Folder 

QDB2 


File Folder 

Qdbscripts 


File Folder 

fj|IM 


File Folder 

tj)JDK 


File Folder 

tj) launchpad 


File Folder 

id) LICENSES 


File Folder 

Id) properties 


File Folder 

depository 


File Folder 

Qresponsefiles 


File Folder 

idlWAS 


File Folder 

idlWAS_SYNC 


File Folder 


1KB 

Setup InFormation 

| launchpad.exe | 

180 KB 

Application 

launchpad.ini 

2 KB 

Configuration Settings 

B launchpad. sh 

6 KB 

SH File 


Figure 6- 1 6 base_dir file list 
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b. Click New installation and enter the installation location. Click Install 
WebSphere Application Server, as shown in Figure 6-17. 



Figure 6-17 Specify the installation location 


c. You will see the warning shown in Figure 6-18. If you have an instance of 
the Installation Manager running, close it. Click OK in the Launchpad 
window to begin the installation of WebSphere Application Server. 



Figure 6-18 Close the running Installation Manager 
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d. When you see the message shown in Figure 6-19, click OK. 




WebSphere Application Server installation was successful and imported into Installation Manager. 


OK 


Figure 6- 1 9 Import installed WebSphere Application Server 


e. Click Install WebSphere Dynamic Process Edition Server to begin the 
installation of the required components (Figure 6-20). 



Figure 6-20 Begin the installation of WebSphere Dynamic Process Edition Server 
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f. Select the components shown in Figure 6-21 and click Next. 



Figure 6-21 Select required components 


On the deployment manager machine, we need to install WebSphere 
Business Monitor and WebSphere Process Server. 

WebSphere Application Server V7.0 Feature Pack for Service Component 
Architect and WebSphere Application Server V7.0 Feature Pack for XML 
are required by WebSphere Process Server (Figure 6-21). 
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Note: The IBM WebSphere Dynamic Process Edition Server is the 
runtime component of the Dynamic Process Edition. It includes the IBM 
Foundation Pack for WebSphere Business Services Fabric V7.0, IBM 
WebSphere Process Server V7.0, and IBM WebSphere Business 
Monitor V7.0. Because we are not including WebSphere Business 
Services Fabric in this scenario, we select the runtime products 
individually. 


g. Review the license agreements, click I accept the terms in the license 
agreements, and then click Next (Figure 6-22). 



Figure 6-22 Review and accept the license 
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h. Click Use the existing package group to use the installed WebSphere 
Application Server and click Next (Figure 6-23). 

WebSphere Dynamic Process Edition V7.0 will be installed into the same 
directory as the specified WebSphere Application Server. 



Figure 6-23 Select the used package group 
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i. Verify the components list and click Next (Figure 6-24). 


Install Packages 

Select the features to install. 


I nstall Licenses^ Location | Features )> Summary |J 

Features 

± □ IBM® WebSphere® Business Monitor 7. 0.0.0 
® O IBM® WebSphere® Process Server 7.0.0.0 

® -0 IBM WebSphere Application Server V7 Feature Pack for Service Component Architecture (SCA) 1.0. 1.0 

0 ID IBM WebSphere Application Server V7 Feature Pack for XML 1. 0.0.0 


□ Show dependencies | Expand All || Collapse All | | Restore I 

Selected by Installation Manager because of dependencies 

Details 

IBM® WebSphere® Business Monitor 7.0.0.0 

If you do not select any features, Business Space and the WebSphere Business Monitor license files are installed. 




J | i; 1 [ 


Figure 6-24 Verify the installation components 
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j. At the summary window, click Install (Figure 6-25). 



Figure 6-25 Review the summary information 
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k. Wait for the installation complete, click None, and then click Finish without 
launching the profile management tool (Figure 6-26). 



Figure 6-26 Complete the installation 
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I. Click Exit to close the launchpad (Figure 6-27). 


IBM WebSphere Dynamic Process Edition Server V7.0 Launchpad 

WebSphere Dynamic 


Process Edition Server 

New installation 

^ New installation 


Installation on existing 

Follow these steps to install a new WebSphere Dynamic Proce 

WebSphere Application 


Server 

1. Install WebSphere Application Server Network Deployme 

WebSphere Dynamic 

a. Specify the installation location: |C:\wdpe7 

Process Edition Server 

b. Install WebSphere Application Server 

database scripts 

IBM Installation Manager will be installed or updated if m 

Message service clients 

Server Network Deployment is automatically imported ini 

installation 

2. Install WebSohere Dynamic Process Edition Server 

Additional software 

When you install WebSphere Dynamic Process Edition S« 

installation 

XML, Feature Pack for SCA, WebSphere Process Server, 

1 El,it 1 

WebSphere Business Fabric Foundation are automatically 


Figure 6-27 Exit IBM WebSphere Dynamic Process Edition Server V7.0 Launchpad 


m. Check the installation logs under the c:\wdpe7\logs directory for 
messages indicating the success or failure of the installation. 

For example, when checking the 

c:\wdpe7\logs\wbi\instal 1 \instal lconfig_server.log file for the 
WebSphere Process Server component, you should see the messages 
shown in Example 6-13. The INSTCONFSUCCESS return code indicates 
success. 

Example 6-13 Installation success message 
<record> 

<date>Apr 14, 2010 5:30:46 PM</date> 

<mi 1 1 i s>1271280646937</mi 1 1 i s> 

<sequence>1076</sequence> 

<1 ogger>com. i bm. ws . i nstal 1 . conf i gmanager . Conf i gManager</l ogger> 
<level>INFO</level> 

<cl ass>com. i bm.ws . i nstal 1 . conf i gmanager .Conf i gManager</cl ass> 
<method>l aunch</method> 

<thread>0</thread> 
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<message>Returning with return code: 

INSTCONFSUCCESS</message> 

</record> 


Open a command-line window and navigate to the c : \wdpe7\bi n directory. 
Execute the versionInfo.bat command to verify the version information 
(Example 6-14). 

Example 6-14 version Info command output 

Product List 

SCA 

installed 

ND 

installed 

WBI 

installed 

WBM 

installed 

XML 

installed 

Installed Product 

Name 

SCA Feature Pack 

Version 

1. 0.1.0 

ID 

SCA 

Build Level 

Z0945.03 

Build Date 

11/9/09 

Architecture 

Intel (32 bit) 

Installed Product 

Name 

IBM WebSphere Application Server - ND 

Version 

7. 0.0. 7 

ID 

ND 

Build Level 

wps0946.04 

Build Date 

11/18/09 

Architecture 

Intel (32 bit) 

Installed Product 

Name 

IBM WebSphere Process Server 

Version 

7. 0.0.0 

ID 

WBI 

Build Level 

of 0948. 05 

Build Date 

11/30/09 

Architecture 

Intel (32 bit) 
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Installed Product 


Name 

IBM WebSphere Business Monitor 

Version 

7. 0.0.0 

ID 

WBM 

Build Level 

oap0948.02 

Build Date 

11/29/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

XML Feature Pack 

Version 

1.0. 0.0 

ID 

XML 

Build Level 

g0945.03 

Build Date 

11/12/09 

Architecture 

Intel (32 bit) 

End Installation 

Status Report 



3. Repeat steps 1 and 2 to install WebSphere Dynamic Process Edition V7.0 to 
c : \wdpe7 on the systems that host the previous WebSphere Process Server 
nodes, in this case, saw016-sys1.itso.ral.ibm.com and 
sawOI 6-sys2.itso.ral.ibm.com. 


Chapter 6. Migrating BPM V6.1.2 to WebSphere Dynamic Process Edition V7.0 


235 



For these two machines, we install the components shown in Figure 6-28. 



Figure 6-28 WebSphere Process Server components 


After installation, execute c:\wdpe7\versionInfo.bat and ensure that you see 
the messages shown in Example 6-15. 

Example 6-15 Version information for the WebSphere Process Server node 
Product List 


SCA installed 
ND installed 
WBI installed 
XML installed 
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Installed Product 


Name 

SCA Feature Pack 

Version 

1.0. 1.0 

ID 

SCA 

Build Level 

Z0945.03 

Build Date 

11/9/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

IBM WebSphere Application Server - ND 

Version 

7. 0.0. 7 

ID 

ND 

Build Level 

wps0946.04 

Build Date 

11/18/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

IBM WebSphere Process Server 

Version 

7. 0.0.0 

ID 

WBI 

Build Level 

of 0948. 05 

Build Date 

11/30/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

XML Feature Pack 

Version 

1.0. 0.0 

ID 

XML 

Build Level 

g0945.03 

Build Date 

11/12/09 

Architecture 

Intel (32 bit) 

End Installation : 

Status Report 
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4. Repeated steps 1 and 2 to install WebSphere Dynamic Process Edition V7.0 
to c:\wdpe7 on the systems that host the previous WebSphere Business 
Monitor nodes. machines, in this case, saw016-sys3.itso.ral.ibm.com and 
saw016-sys4.itso.ral.ibm.com. For these two machines, we install the 
components shown in Figure 6-29. 



Figure 6-29 WebSphere Business Monitor components 


After the installation, execute c:\wdpe7\versionInfo.bat and ensure that you 
see the messages shown in Example 6-16. 

Example 6- 1 6 Version information for WebSphere Business Monitor node 
Product List 


ND 


installed 
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WBM 

XML 


installed 

installed 


Installed Product 


Name 

IBM WebSphere Application Server - ND 

Version 

7. 0.0. 7 

ID 

ND 

Build Level 

wps0946.04 

Build Date 

11/18/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

IBM WebSphere Business Monitor 

Version 

7. 0.0.0 

ID 

WBM 

Build Level 

oap0948.02 

Build Date 

11/29/09 

Architecture 

Intel (32 bit) 

Installed Product 


Name 

XML Feature Pack 

Version 

1.0. 0.0 

ID 

XML 

Build Level 

g0945.03 

Build Date 

11/12/09 

Architecture 

Intel (32 bit) 

End Installation 

Status Report 



6.4.4 Back up the new installations 

As a best practice, before beginning the migration, back up the clean WebSphere 
Dynamic Process Edition V7.0 installation on each machine. With this backup, 
you can quickly restore from a migration failure without reinstalling WebSphere 
Dynamic Process Edition V7.0. You can use a compression tool to back up the 
c:\wdpe7 directory. 


Chapter 6. Migrating BPM V6.1 .2 to WebSphere Dynamic Process Edition V7.0 239 



6.5 Migrate the source environment 


This section provides instructions about migrating the Version 6.1.2.x source 
environment to WebSphere Dynamic Process Edition V7.0. We demonstrate 
using both the runtime migration command-line tools and the migration GUI 
wizard tool to migrate a profile. 

According to our topology, Figure 6-30 lists the steps we have to do for our 
runtime migration. The first four steps are already complete. 







Stop Dmgr, all Application Servers and Node Agents 




Backup source runtime Environment and Databases 




Install WebSphere Dynamic Process Edition V7.0 




Backup target runtime environment 




Migrate deployment manager 

1 

1 

1 


Upgrade Schema of common and monitor databases 

1 

1 


Start up target deployment manager 

1 

1 


Migrate all custom nodes one by one 

1 

1 


Migrate all clusters one by one 

1 

1 

1 


Run syncNode from Each Custom Node 

1 

1 

1 


Migrate BPC data 

1 

1 


Migrate BPC Observer (Optional) 

1 

1 


Migrate Alphablox repository 

1 

1 


Migrate Business Space 

1 

1 

1 


Deploy Monitor scheduler service 

1 

1 

1 


Update Monitor configuration 

1 

1 

| 


Done 

1 

1 


V 


Figure 6-30 Migration steps 
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6.5.1 Migrate the deployment manager using command-line utilities 

You can either use the GUI or command-line utilities for profile migration. We 
migrate the deployment manager profile by using the command-line utilities. 


Note: Remember that after you have performed the migration, you should not 
start the source deployment manager again. 


Create a snapshot of the deployment manager configuration 

The first step is to create a snapshot of the deployment manager configuration. 

Perform the following steps: 

1. Log into the deployment manager machine using the administrator user ID. 

2. Launch a command-line window and navigate to the bi n directory under the 
target product installation root by running the following command: 

C:\>cd c:\wdpe7\bin 

3. Execute the following command to get more detailed usage information for 
the BPMSnapshotSourceProfile.bat command: 

C : \wdpe7\bi n>BPMSnapshotSourceProf i 1 e . bat -hel p 

4. Run BPMSnapshotSourceProf i 1 e . bat (Example 6-1 7) to copy the deployment 
manager configuration files to a snapshot directory. 

Example 6- 1 7 Example of the BPMSnapshotSourceProfile. bat command 

C:\wdpe7\bin>BPMSnapshotSourceProfile.bat -trace fine -traceFile 
c:\MigrationSnapshot\WDPEDmgr\MigrationWDPE.trace c:\wdpe612 
WDPEDmgr c : \Mi grati onSnapshot\WDPEDmgr 


- By default, the BPMSnapshotSourceProfile.bat command does not print 
any trace messages. We use the -trace fine option to enable a fine level 
trace. 

- The -traceFile c:\MigrationSnapshot\WDPEDmgr\MigrationWDPE.trace 
option specifies the trace file location and name. 

- The c:\wdpe612 parameter specifies the source product installation root. 

- The WDPEDmgr parameter is the source deployment manager profile 
name. This name must be exactly the same as the source profile name. 
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- The c:\MigrationSnapshot\WDPEDmgr parameter is the snapshot 

directory. The command will copy the configuration files into this directory. 
As a best practice, the snapshot directory should not be located in the 
source or target product installation directories. Also, if you have multiple 
profiles on the same machine, specify different snapshot directories for 
each of them. 

The command output is shown in Example 6-18. You should see the 
successful message at the end. 

Example 6-18 The command output of BPMSnapshotSourceProfile.bat 

C:\wdpe7\bin>BPMSnapshotSourceProfile.bat -trace fine -traceFile 

c:\MigrationSnapshot\WDPEDmgr\MigrationWDPE.trace c:\wdpe612 

WDPEDmgr c : \Mi grati onSnapshot\WDPEDmgr 

IBM WebSphere Business Integration, Release 7.0 

Product Migration BPMSnapshotSourceProfi 1 e tool 

Copyright IBM Corp., 2009 

sourceWASHome = [C:\wdpe612] 
sourceProfileName: [WDPEDmgr] 

CWMC00200I : Information is being logged to the 

C:\MigrationSnapshot\WDPEDmgr\logs\BPMSnapshotSourceProfile.WDPED 
mgr.Mon-Apr-19-19.12.20-EDT-2010.log file. 

-traceString 

-traceFile 

c:\MigrationSnapshot\WDPEDmgr\MigrationWDPE.trace 
CWMC00209I : The C:\wdpe7\bin\WASPreUpgrade.bat 
c:\MigrationSnapshot\WDPEDmgr c:\wdpe612 -oldProfile WDPEDmgr 
-machineChange true -traceString *=fine=enabled -traceFile 
c:\MigrationSnapshot\WDPEDmgr\MigrationWDPE.trace WebSphere 
Appl i cation 

Server utility has been invoked. 

CWMC00208I : See the following log file for information: 

C : \Migrat i onSnapshot\WDPEDmgr\l ogs\WASPreUpgrade . <TIMESTAMP> . 1 og 


CWMC00224I : The WebSphere Application Server utility has 
completed. 

CWMC00208I : See the following log file for information: 

C:\MigrationSnapshot\WDP 

EDmgr\l ogs\WASPreUpgrade.<TIMESTAMP>. 1 og 

CWMC00823I : The BPMSnapshotSourceProfi le command finished 
successfully. 
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o. Examine the log files mention in the command output in Example 6-18 on 
page 242 (highlight in bold) under C:\MigrationSnapshot\logs to make 
sure that there are no exceptions in the logs. 

In this case, we check 

BPMSnapshotSourceProfile.WDPEDmgr.Mon-Apr-19-19. 12.20- EDT-2010.1o 
g and find the message shown in Example 6-19, indicating that the 
command was successful. 

Example 6-19 Success message in the BPMSnapshotSourceProifle logs 

[4/19/10 7:15:34 PM EDT] 0 BPMSnapshotNode I main(String[] args) 
CWMC00823I : The BPMSnapshotSourceProfi le command finished 
successful ly. 


In WASPreUpgrade. Mon-Apr- 19- 19. 12.30-2010.log, we see the success 
message at the end of Example 6-20. 

Example 6-20 Success message in the WASPreUpgrade logs 
MIGR0420I: The first step of migration completed successfully. 


Create the target profile 

The second step is to create the target profile. 

Perform the following steps: 

1. Run the BPMCreateTargetProfile.bat command (Example 6-21) to create 
the target profile. 

Example 6-21 Example of the BPMCreateTargetProfile.bat command 

C:\wdpe7\bin>BPMCreateTargetProfile.bat -target Prof i 1 eName WDPEDmgr 
-targetProf i 1 eDi rectory c : \wdpe7\prof i 1 es\WDPEDmgr -remoteMi grati on 
false c:\MigrationSnapshot\WDPEDmgr WDPEDmgr 


- The -targetProfileName WDPEDmgr option identifies the target 
deployment manager profile name that will be created under the 
WebSphere Dynamic Process Edition V7.0 installation. It can be different 
from the source deployment manager profile name. Here we specified the 
same profile name for the target profile. 

- The -targetProfileDirectory c:\wdpe7\profiles\WDPEDmgr option is the 
target profile directory. 

- The -remoteMigration false option specifies that this is not a remote 
migration scenario. You should always specify false in network deployment 
topology, as a remote migration scenario is not applicable. 
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- The c:\MigrationSnapshot\WDPEDmgr parameter is the migration 
snapshot directory created by the BPMSnapshotSourceProfile.bat 
command in “Create a snapshot of the deployment manager 
configuration” on page 241 . 

- The WDPEDmgr parameter is the source deployment manager profile 
name that will be migrated. 


Note: Target profiles cannot be created with the PMT GUI wizard or the 
manageprof i 1 es . bat command. They can only be created with the BPM 
migration tool (command-line or GUI migration wizard). 


The command output is shown in Example 6-22. 

Example 6-22 The command output of BPMCreateTargetProfile.bat 

C : \wdpe7\bi n>BPMCreateTargetProf i 1 e . bat -targetProf i 1 eName WDPEDmgr 
-target Prof i 1 eDi rectory c : \wdpe7\prof i 1 es\WDPEDmgr -remoteMi grati on 
false c:\MigrationSnapshot\WDPEDmgr WDPEDmgr 

argsO value is -targetProf i 1 eName 

argsl value is WDPEDmgr 

args2 value is -targetProf i 1 eDi rectory 

args3 value is c:\wdpe7\profiles\WDPEDmgr 

args4 value is -remoteMi grati on 

args5 value is false 

args6 value is c:\MigrationSnapshot\WDPEDmgr 
args7 value is WDPEDmgr 

CWMC00200I : Information is being logged to the 

c:\MigrationSnapshot\WDPEDmgr\logs\BPMCreateTargetProfile.WDPEDmgr.M 
on-Apr-19-19.18.36-EDT-2010.log file. 

CWMC00209I : The C:\wdpe7\bin\manageprofiles.bat -wi nservi ceCheck 
false -nodeName WDPECel 1 Manager -wbmDBPassword UNSET -omitAction 
sampleslnstal 1 AndConfig -hostName saw007-sysl -wbmDBUserld UNSET 
-cell Name WDPECel 1 -profilePath C:\wdpe7\profiles\WDPEDmgr 
-wbmDBDelayConfig true -create -profil eName WDPEDmgr -tempi atePath 
C:\wdpe7\profi leTempl ates\dmgr.wbi server -wbmDBSchemaName MONITOR 
-createDefaultProfileForMi grati on true -enableAdminSecurity false 
WebSphere Application Server utility has been invoked.. 
INSTCONFSUCCESS: Success: Profile WDPEDmgr now exists. Please 
consul t C:\wdpe7\profiles\WDPEDmgr\logs\AboutThisProfile.txt for 
more information about this profile. 

CWMC00838I: The profile was created or augmented successfully. 
CWMC00209I : The C:\wdpe7\bin\manageprofiles.bat -tempi atePath 
C: /wdpe7/prof i 1 eTempl ates/wbmoni tor/dmgr -augment -dbDel ayConf i g 
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true -profileName WDPEDmgr -createDefaultProfileForMigration true 
-wbmDBDelayConfig true -wbmDBSchemaName MONITOR -wbmDBUserld UNSET 
-wbmDBPassword UNSET WebSphere Application Server utility has been 
invoked. . 

INSTCONFSUCCESS: Profile augmentation succeeded. 

CWMC00838I: The profile was created or augmented successfully. 


2. Examine the log files and the AboutThisProfile.txt file in the command 
output shown in Example 6-22 on page 244 (highlights in bold): 

a. Check 

BPMCreateTargetProfile.WDPEDmgr.Mon-Apr-19-19.18.36-EDT-2010.log 
to make sure that there are no exceptions in the logs. 

b. Check the profile creation log files under 
target_install_root/ logs/manageprofiles/ for fatal profile errors. The 
expected messages showing a successful execution are shown in 
Example 6-23. 

Example 6-23 Success message in the profile creation log file 

<message>INSTCONFSUCCESS: Profile augmentation 
succeeded. </message> 

<message>Returning with return code: INSTCONFSUCCESS</message> 


c. Check the profile augment log files under 

target_install_root/ logs/manageprofiles/ for fatal profile errors. You 
should see the successful execution message in Example 6-24. 

Example 6-24 Success message in the profile augmentation log file 

<message>INSTCONFSUCCESS: Profile augmentation 
succeeded. </message> 

<message>Returning with return code: INSTCONFSUCCESS</message> 


d. Check to see if the AboutThisProfile.txt file has been created 

(Example 6-25). This file is created after the profile is successfully created. 
You can also verify the values you entered for node name, cell name, port, 
and so on. 

Example 6-25 Content of AboutThisProfile. txt 

Application server environment to create: Management 
Locati on : C:\wdpe7\profi 1 es\WDPEDmgr 
Disk space required: 30 MB 
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Profile name: WDPEDmgr 

Make this profile the default: True 

Node name: WDPECel 1 Manager 

Cell name: WDPECel 1 

Host name: saw007-sysl 

Enable administrative security (recommended): False 
Administrative console port: 9060 
Administrative console secure port: 9043 
Management bootstrap port: 9809 
Management SOAP connector port: 8879 
Run Management as a service: False 


Migrate the source profile to the target profile 

The third step is to migrate the source profile to the target profile. 

Perform the following steps: 

1. Issue the BPMMigrateProfile.bat command (Example 6-26) to migrate the 
source profile to the target profile. 

Example 6-26 Example of the BPMMigrationProfile.bat command 

C:\wdpe7\bin>BPMMigrateProfile.bat -username admin -password admin 
-targetProfileName WDPEDmgr -scriptCompatibility false 
-keepSourceDMgrEnabled false -keepAppDi rectory false -trace fine 
-traceFi 1 e c:\Mi grati onSnapshot\WDPEDmgr\DmgrMi grati on . trace 
c:\MigrationSnapshot\WDPEDmgr WDPEDmgr 


- The -username admin -password admin option indicates the source 
profile’s administrative user ID and password. This is required if global 
security is enabled on the source environment. Also, the user should have 
the operator or administrator role. Here we use the primary administrative 
user ID. 

- The -targetProfileName WDPEDmgr option is the target deployment 
manager profile name created by the BPMCreateTargetProfile.bat 
command in “Create the target profile” on page 243. If the name of the 
target profile is different from that of the source profile, this option is 
required. 

- The -scriptCompatibility false option specifies that the migration should 
create WebSphere Application Server V7.0 configuration definitions 
instead of Version 6.x. The default value is true. 
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Note: You can specify true to minimize the impacts to existing 
administration scripts, if you have existing wsadmin scripts or programs 
that use third-party configuration APIs to create or modify Version 6.x. 

Specifying true is only a temporary fix. When all nodes in the 
environment are at Version 7.0 level, you should perform the following 
actions: 

1 . Modify your administration scripts to use all of the Version 7.0 
settings. 

2. UsetheconvertScriptCompatibility.bat command under the bin 
directory of target profile installation root to convert the 
configurations to match all of the Version 7.0 settings. For more 
details, refer to the Information Center topic found at the following 
address: 

http://publib.boulder.ibm.com/infocenter/wasinfo/V7.0r0/inde 
x . j sp?topi c=/com. i bm. websphere .mi grati on . nd . doc/i nfo/ae/ae/r 
mi g_convertscri pt . html 


- The -keepSourceDMgrEnabled false option specifies that the source 
deployment manager profile is disabled. This ensures that the source and 
target deployment managers are not started at the same time. This option 
is pertinent only for deployment manager profiles. 


Note: Specify true for this option with care. Specifying true means that 
any configuration changes made in the old configuration during 
migration might not be migrated. 


- The -keepAppDirectory false option specifies that all applications will be 
installed in a different directories from where they are currently located. 
The best practice is to specify fal se. 


Note: Specifying the option as true means that the location is shared 
by WebSphere Application Server V6.x and V7.0. It will bring 
mixed-node support limitations and administration risk. 


- The -trace fine option enables the fine level trace. Use trace level al 1 with 
care; it can generate a huge size trace file. 

- The -traceFile c:\MigrationSnapshot\WDPEDmgr\DmgrMigration.trace 
option specifies the file where the trace information is written. 
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- c:\MigrationSnapshot\WDPEDmgr is the migration snapshot directory 
created by the BPMSnapshotSourceProfile.bat command in “Create a 
snapshot of the deployment manager configuration” on page 241 . 

- WDPEDmgr is the source deployment manager profile name that will be 
migrated. 

For more details, refer to the Information Center topic found at the following 
address: 

http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/topic/com 
. i bm . websphere . wps . doc/doc/rmi g_vtv_bpmmi grateprof i 1 e . html 
The command output is shown in Example 6-27. 

Example 6-27 Output of BPMMigrationProfile.bat (the output is truncated) 

C:\wdpe7\bin>BPMMi grateProfile.bat -username admin -password admin 
-targetProfileName WDPEDmgr -scriptCompatibility false 
-keepSourceDMgrEnabled false -keepAppDirectory false -trace fine 
-traceFi 1 e c:\Mi grat i onSnapshot\WDPEDmgr\DmgrMi grati o 
n. trace c:\MigrationSnapshot\WDPEDmgr WDPEDmgr 
IBM WebSphere Business Integration, Release 7.0 
Product Migration BPMMi grateProf i 1 e tool 
Copyright IBM Corp., 2009 

backupDirectoryRoot = C:\MigrationSnapshot\WDPEDmgr 
Attempting to get the source profile name... 
sourceProfileName = [WDPEDmgr] 
target profile name = [WDPEDmgr] 

Checking username/password... 

CWMC00200I : Information is being logged to the 

C:\MigrationSnapshot\WDPEDmgr\logs\BPMMigrateProfile.WDPEDmgr.Mon-Ap 
r-19-19.47.14-EDT-2010.log file. 

CWMC00209I : The C:\wdpe7\bin\WASPostUpgrade.bat 
c:\MigrationSnapshot\WDPEDmgr -oldProfile WDPEDmgr -username admin 
-password ***** -profileName WDPEDmgr -scrip 

tCompatibility false -keepDmgrEnabled false -keepAppDirectory false 
-traceString *=fine=enabled -traceFi le 
c : \Mi grati onSnapshot\WDPEDmgr\DmgrMi grati on . trace Web 
Sphere Application Server utility has been invoked. 

CWMC00208I : See the following log file for information: 

C : \Migrat i onSnapshot\WDPEDmgr\l ogs\WASPostUpgrade .WDPEDmgr . <TIMESTAM 
P> . 1 og 


CWMC00224I: The WebSphere Application Server utility has completed. 
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CWMC00208I : See the following log file for information: 
C:\MigrationSnapshot\WDPEDmgr\logs\WASPostUpgrade.WDPEDmgr.<TIMESTAM 
P> . 1 og 

CWMC00820I: The ws_ant command is being invoked with the 

C : \wdpe7\bi n\BPMProf i 1 ellpgradeWrapper.bat 

C : \wdpe7\prof i 1 es\WDPEDmgr\bi n\ws_ant . bat -f 

C:\wdpe7\uti 1 \BPMProfi 1 eUpgrade.ant -Duser=admin 

-Dwbi . upgrade . previous . prof i 1 eName=WDPEDmgr -Dpassword=***** 

-Duser . i nstal 1 . root=C : \wdpe7\prof i 1 es\WDPEDmgr 

-Dbpm. upgrade . previous . prof i 1 eName=WDPEDmgr 

-Dmi grati onDi r=C :/Mi grati onSnapshot/WDPEDmgr command . 

CWMC00208I : See the following log file for information: 

C:\MigrationSnapshot\WDPEDmgr\logs\BPMProfileUpgrade.WDPEDmgr.<TIMES 

TAMP>.log 


CWMC00822I : The BPMMigrateProfile command finished successfully. 
CWMC00850I: See the migration documentation for additional migration 
tasks that are specific to your configuration such as upgrading 
database schemas and/or running BPMMigrateCl uster command for 
clusters. 


3. Examine the log files highlighted in bold in Example 6-28 and make sure that 
there are no exceptions: 

- In the BPMMigrateProfile.WDPEDmgr.Mon-Apr-19-19.47.14-EDT-2010.log 
file, check for the messages in Example 6-28 to ensure that there has 
been a successful execution. 

Example 6-28 Success message in BPMMigrateProfile log file 

[4/19/10 8:15:28 PM EDT] 0 BPMMigrateNode I main(String[] args) 
CWMC00822I : The BPMMigrateProfile command finished successfully. 
[4/19/10 8:15:28 PM EDT] 0 BPMMigrateNode I main(String[] args) 
CWMC00850I: See the migration documentation for additional 
migration tasks that are specific to your configuration such as 
upgrading database schemas and/or running BPMMigrateCl uster 
command for clusters. 


- In the WASPostUpgrade.WDPEDmgr.Mon-Apr-19-19.47.17-2010.log file, we 
can see the successful message at the end of the example shown in 
Example 6-29. 

Example 6-29 Success message in WASPostUpgrade log file 

MIGR0271W: Migration completed successfully, with one or more 
warnings. 
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- In the BPMProfileUpgrade.WDPEDmgr.Mon-Apr-19-20.11.46-2010.log, file, 
we can see the successful message at the end of the example shown in 
Example 6-30. 

Example 6-30 Success message in BPMProfileUpgrade log file 
BUILD SUCCESSFUL 


6.5.2 Upgrade common database schema 

Next, we upgrade the common database schema. Do not start the deployment 
manager before the database schema is upgraded. 

Prepare the scripts 

Prepare the scripts by performing the following steps: 

1 . To upgrade the common database schema, copy the entire 

target _install_root\ dbscripts\CommonDB folder from the target deployment 
manager system to a directory on the DB2 system. 

In this case, we copy the folder to c:\saw016\V7.0 on 
saw007-sys2.itso.ral .ibm.com in our environment. 

As a best practice, copy the whole folder to the DB2 system. 

2. Log in to the database system as the db2admin user. 

3. Change to the dbscripts folder (c:\saw016\V7.0\CommonDB\DB2). 

4. We now need to change the current schema in upgradeSchemaTables.bat, 
because the schema name of our common database is different from the DB2 
user ID (see Table 6-2 on page 198). 

Open the upgradeSchemaT abl es . bat file with an editor and look for the 
following line: 

@db2 set current schema=%DB_USER% 

Change the schema name to the common database schema. In our example, 
this line becomes @db2 set current schema=COMMONDB. 


Important: If you are not using the database user ID as the schema name 
for the common database, you need to modify the current schema in 
upgradeSchemaTabl es . bat. 


Execute the scripts 

Execute the scripts by performing the following steps: 

1 . Log in to the database server as the db2admin user. 
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2. Open a DB2 command prompt and change to the directory where the scripts 
are located: 

cd c:\saw016\V7.0\CommonDB\DB2 

3. Run the upgradeSchema.bat -help command if you need usage information: 
C:\saw016\V7.0\CommonDB\DB2>upgradeSchema.bat -help 

4. We use the following command to upgrade common database schema 
(Example 6-31). Make sure each SQL is executed successfully. 

Example 6-31 Example of upgradeSchema.bat 

C:\saw016\V7. 0\CommonDB\DB2>upgradeSchema. bat wbiserver 612 WPRCSDB 
db2admin 


- wbiserver is the migrated profileType for WebSphere Process Server. 

- 612 means that the source product version is WebSphere Process Server 
V6.1.2.X. 

- WPRCSDB is the common database name. 

- db2admin is the database user who can execute the command scripts. 

Upgrade verification 

Verify the upgrade by performing the following steps: 

1. Check c:\saw016\V7.0\612.log and make sure that the five SQL scripts for 
WebSphere Process Server V6.1 .2 are executed (Example 6-32). 

Example 6-32 SQL scripts that are executed during upgrade 
upgradeSchema612_CommonDB.sql 
upgradeSchema612_Di rectDepl oy . sql 
upgradeSchema612_governancerepository.sql 
upgradeSchema612_rel ati onshi pServi ce . sql 
wbi server_upgradeSchema612_Recovery . sql 


2. Check the table list by using the command-line interface for DB2 
(Example 6-33). 

Example 6-33 List table command for common database 
db2 connect to WPRCSDB user db2admin using password 
db2 list tables for schema COMMONDB 
db2 terminate 
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Make sure the tables shown in Example 6-34 are created. 

Example 6-34 Table list for command database after upgrade (the output is 
truncated) 


Table/View 


Schema 


APPTIMESTAMP 

BYTESTORE 

BYTESTOREOVERFLOW 

CUSTPROPERTIES 

D2D_C0NTENT 

D2D_ITEM 

D2D_L0CK 

D2D_MESSAGE 

D2D_METADATA 

D2D_PR0GRESS 

FAILEDEVENTBOTYPES 

FAILEDEVENTDETAIL 

FAILEDEVENTMESSAGE 

FAILEDEVENTS 

MEDIATION_TICKETS 

PERSISTENTLOCK 

RELN_METADATA_T 

RELN_VIEW_META_T 

SCHEMAVERSIONINFO 

WSCH_LMGR 

WSCH_LMPR 

WSCH_TASK 

WSCH_TREG 

W_ARTIFACT_BLOB 

W_DBVERSION 

W_LIT_DOUBLE 

W_LIT_FLOAT 

W_LIT_L0NG 

W_L0CALE 

W_NAMESPACE 

W_OBJ_LIT_ANY 

W_OBJ_LIT_DATE 

W_OBJ_LIT_DATETIME 

W_OBJ_LIT_STRING 

W_OBJ_PRED_INDEX 

W_OBJ_SUBJ_INDEX 

W_PRED_OBJ_INDEX 

W_PRED_SUBJ_INDEX 

W_STATEMENT 


COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 

COMMONDB 
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W_SUBJ_OBJ_I NDEX COMMONDB 
W_SUBJ_PRED_INDEX COMMONDB 
W_URI COMMONDB 
INVERSION COMMONDB 

43 record(s) selected. 


6.5.3 Upgrade the monitor database schema using the DDL files 

The monitor database schema should be updated before you start the target 
deployment manager. 

Prepare the scripts 

Prepare the scripts by performing the following steps: 

1 . To upgrade monitor database schema, copy the entire 

target _install _root\ dbscripts\Monitor folder from the target deployment 
manager system to c:\saw016\V7.0 on the DB2 system. As a best practice, 
you should copy the whole folder to the DB2 system. 

2. Log in to the database system as the db2admin user. 

3. Change to the dbscripts folder (c:\saw016\V7.0\Monitor\DB2). 

4. Edit the upgradeSchema61.sql file: 

a. Change each occurrence of @SCHEMA@ to your source monitor 
database schema name (for example, MONITOR) 

b. Change each occurrence of @TSDIR@ to your chosen table space 
location and table space prefix. In our example, these occurrences are 

C : \DBTabl espace\RMDEFAULTTS32S, where C:\DBTabl espace\ is the table 
space location and RMDEFAULTTS32S is the table space prefix. The updated 
line (added content is highlighted in bold) is shown in Example 6-35. 

Example 6-35 Updated lines for upgradeSchema61 .sql (the context is truncated) 

— User Temporary Tablespace added for MQT Support 
CREATE USER TEMPORARY TABLESPACE UTMPTS32K PAGESIZE 32 K 
MANAGED BY SYSTEM USING 

('C:\DBTablespace\RMDEFAULTTS32S_UTMPTS32K' ) 

EXTENTSIZE 8 OVERHEAD 10.5 PREFETCHSIZE 32 TRANSFERRATE 0.14 
BUFFERP00L TMPBP32K; 
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Execute the scripts 

Execute the scripts by performing the following steps: 

1 . Open a DB2 command prompt and change to the db2scripts directory: 
cd c:\saw016\V7.0\Monitor\DB2 

2. Use the following command to upgrade the monitor database schema 
(Example 6-36). Make sure each SQL is executed successfully. 

Example 6-36 Example of an upgraded monitor schema command 

db2 connect to MONITOR user db2admin using password 
db2 -tvf upgradeSchema61.sql 


Upgrade verification 

To verify the upgrade, we list the tables in the MONITOR schema, as shown in 
Example 6-37. 

Example 6-37 List table command for MONITOR database 
db2 connect to MONITOR user db2admin using password 
db2 list tables for schema MONITOR 
db2 terminate 


The expected output is shown in Example 6-38. 

Example 6-38 Table list for command database after upgrade (the output is truncated) 


Table/View Schema 


ABX_L00KUP MONITOR 
ABX_LOOKUP_VALUES MONITOR 
ABX_OBJECTS MONITOR 
ABX_PROPERTY_MAP MONITOR 
ABX_TYPES MONITOR 
ABX_VERSION MONITOR 
ACTION MONITOR 
ACTION_HANDLER_CTRL_T MONITOR 
ACTION_MANAGER_PROP_T MONITOR 
ACTI0N_T MONITOR 
ACT_HNDLR_T MONITOR 
AC T_MG R_A L ERTS_T MONITOR 
ACT_MGR_PROP MONITOR 
ACT_SITUATION_T MONITOR 
ACT_SIT_TRIG_T MONITOR 
ACT_TMPLT MONITOR 
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ACT_TMPLT_T 

ALERTS 

ATAMATCH_T 

CEI_SERVER_SOURCE_T 

D2D_C0NTENT 

D2D_ITEM 

D2D_L0CK 

D2D_MESSAGE 

D2D_METADATA 

D2D_PR0GRESS 

DASHBOARD_ALERT_T 

DAS H BOARD_DAT A_T 

DIM_TIME 

DMS_HISTORY_T 

DMS_METADATA_T 

DMS_TRACE_T 

DQ_DEAD_EVENT_T 

DQ_MODEL_VERSION_T 

DS S_MO D E L_ARC HIV E_V E R_CO N F I G_T 

DS S_MO D E L_CO N F I G_T 

DS S_MO D E L_CU B E_S TATU S_T 

DSS_MODEL_SERVICE_CONFIG_T 

DSS_MODEL_SERVICE_VER_CONFIG_T 

EQ_FAILED_EVENT_T 

EQFEIDS 

EQ_INSTANCE_T 

EQ_MODEL_VERSION_T 

ETAACTRL_T 

ETAMATCH 

ETAMATCH_T 

KPI_HISTORY_T 

KPI_TS_PREDICTION_MODEL_T 

KPI_TS_PREDICTION_T 

META_DIMENSION_T 

META_DIM_ATTR_T 

META_KPI_CONTEXT_T 

META_KPI_DEPENDENCY_T 

META_KPI_METRIC_FILTER_T 

META_KPI_RANG E_T 

META_KPI_T 

META_MEASURE_T 

META_MODEL_STEP_T 

META_MODEL_T 

META_MODEL_UNVERSIONED_T 

META_MONITOR_CONTEXT_T 


MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 

MONITOR 
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METAMON I TOR_METRI C_T MONITOR 
META_OUTBOUND_EVENT_T MONITOR 
MM_TO_WPS_PT MONITOR 
MODERATOR_NEXT_ID MONITOR 
MONSCHED_LMGR MONITOR 
MONSCHED_LMPR MONITOR 
MONSCHED_TASK MONITOR 
MONSCHED_TREG MONITOR 
PLUGJVC MONITOR 
PLUG_SVC_T MONITOR 
RAT_AUTH_DOMAIN MONITOR 
RAT_PARTY_ROLES MONITOR 
RAT_RESOURCE_GROUPS MONITOR 
RAT_SUPERUSERS MONITOR 
RAT_UPDATE_MONITOR MONITOR 
RECORDED_EVENTS MONITOR 
RECORDED_EVENTS_MODELVERSIONS MONITOR 
SCHEMA_VERSION MONITOR 
SUBSCRIBED_USER_T MONITOR 
USER_DATA_T MONITOR 


81 record(s) selected. 


6.5.4 Update the JDBC driver 

Update the JDBC driver on the WebSphere Dynamic Process Edition V7.0 
runtime by performing the following steps: 

1 . From the DB2 system, copy the following JDBC driver jar files under 
C:\IBM\DB295\java\ to the JDBC driver directory on each WebSphere 
Dynamic Process Edition V7.0 runtime machine: 
db2jcc.jar 

db2jcc_l icense_cu.jar 


256 Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 



Table 6-7 shows the information about the JDBC driver location on each of the 
machines in our environment. 

Table 6-7 JDBC driver locations 


Host name 

Target JDBC driver directory 

saw007-sys1 .itso.ral.ibm.com 

C : \wdpe7\uni versal Dri ver_wbi \1 1 b 
C : \wdpe7\uni versal Dri ver . wbm\l i b 
C : \wdpe7\uni versal Dri ver\l i b 

saw016-sys1 .itso.ral.ibm.com 

C : \wdpe7\uni versal Dri ver_wbi \1 i b 

saw0 1 6-sys2 . itso. ral . ibm .com 

C : \wdpe7\uni versal Dri ver_wbi \1 i b 

saw0 1 6-sys3 . itso. ral . ibm .com 

C : \wdpe7\uni versal Dri ver . wbm\l i b 

saw0 1 6-sys4. itso. ral . ibm .com 

C : \wdpe7\uni versal Dri ver . wbm\l i b 


6.5.5 Start the target deployment manager 

Start the new Version 7.0 deployment manager by performing the following 
steps: 

1 . Log in to the deployment manager machine with the administrator user ID. 

2. Navigate to target_dmgr _profi lejrootl bi n directory, for example, 

C : \wdpe7\prof i 1 es\WDPEDmgr\bi n. 

3. Execute the startManager.bat command. 

4. Check C : \wdpe7\prof i 1 es\WDPEDmgr\l ogs\dmgr\SystemOut . 1 og to make sure 
that there are no exceptions. 

6.5.6 Migrate the first WebSphere Process Server custom node 

After the target deployment manager is started, we can migrate the WebSphere 
Process Server custom nodes. 


Note: 

► During custom node migration, WebSphere Dynamic Process Edition V7.0 
deployment manager must be running. 

► Custom nodes must be migrated one at a time. 


Here we migrate the first WebSphere Process Server custom node profile 
(WPSCustOI in our environment) by using command-line utilities. 
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Create a snapshot of the source custom profile configuration 

Just like the deployment manager migration, the first step is to create the 
snapshot for the source WebSphere Process Server custom profile. 

Perform the following steps: 

1 . Log in to the first WebSphere Process Server custom node machine 
(saw016-sys1.itso.ral.ibm.com in our environment) using the administrator 
user ID. 

2. Navigate to the bi n directory under target product installation root 
(C:\wdpe7\bin). 

3. Run BPMSnapshotSourceProf i 1 e . bat (Example 6-39) to copy the source 
WPSCustOI configuration files to a snapshot directory. 

Example 6-39 Example of the BPMSnapshotSourceProfile.bat command 

C:\wdpe7\bin>BPMSnapshotSourceProfile.bat -trace fine -traceFile 
c : \Mi grati onSnapshot\WPSCust01\WPSCust01Mi grati on .trace c : \wdpe612 
WPSCustOI c : \Mi grati onSnapshot\WPSCust01 


4. Examine the logs under C:\MigrationSnapshot\WPSCust01\logs and make 
sure that there are no exceptions in the logs. 

- In 

BPMSnapshotSourceProfile. WPSCustOI. Mon-Apr-19-20. 34. 45-EDT-2010. 1 
og, we can see a success message (see Example 6-40) at the end of the 
example. 

Example 6-40 Success message in the BPMSnapshotSourceProifle logs 
[4/19/10 8:36:17 PM EDT] 0 BPMSnapshotNode I main(String[] args) 
CWMC00823I : The BPMSnapshotSourceProfile command finished 
successful ly. 


- In WASPrellpgrade.Mon-Apr-19-20.34.54-2010.log, we can see a success 
message (see Example 6-41 ) at the end of the message. 

Example 6-4 1 Successful message in the WASPreUpgrade logs 
MIGR0303I: The existing Application Server environment is save 
MIGR0420I: The first step of migration completed successfully. 
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Create the target profile 

The next step is to create the target profile by performing the following steps: 

1 . Run BPMCreateTargetProfile.bat (Example 6-42) to create the target 
profile. 

Example 6-42 Example of the BPMCreateTargetProfile command 

C:\wdpe7\bi n>BPMCreateTargetProf i 1 e . bat -target Prof i 1 eName 
WPSCustOl -targetProfileDi rectory c:\wdpe7\profiles\WPSCust01 
-remoteMigration false c:\MigrationSnapshot\WPSCust01 WPSCustOl 


2. ExaminethelogandAboutThisProfile.txt files listed in the command 
output: 

- At the end of the command output, there should be a message indicating 
that the profile was created successfully (Example 6-43). 

Example 6-43 Success message in the command output 

CWMC00838I: The profile was created or augmented successfully. 


- Check the BPMCreateTargetProf i 1 e log and make sure that there are no 
exceptions in the logs. The log file in this scenario is stored at: 

C:\MigrationSnapshot\WPSCust01\logs\BPMCreateTargetProfile.WPSCus 

t01.Mon-Apr-19-20.39.00-EDT-2010.log 

- Check the profile creation log files for any fatal profile errors 
(C : \wdpe7\l ogsVnanageprof i 1 es\WPSCust01_create .log). 

The message in Example 6-44 indicates that the profile was created 
successfully. 

Example 6-44 Profile creation or augmentation successful message 
<message>Returning with return code: INSTCONFSUCCESS</message> 


- Check C:\wdpe7\profi 1 es\WPSCust01\l ogs\AboutThis Prof i le.txt 

(Example 6-45). This file is created after the profile is successfully created. 
You can also verify the values you entered for node name, cell name, port, 
and so on. 

Example 6-45 Content of AboutThisProfile. txt 

Application server environment to create: Custom 

Locati on : C:\wdpe7\profi 1 es\WPSCust01 

Disk space required: 10 MB 

Profile name: WPSCustOl 

Make this profile the default: True 
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Node name: WPSNodeOl 

Host name: saw016-sysl 

Federate to deployment manager: False 


Migrate the source profile to the target profile 

Perform the migration of the profile by performing the following steps: 

1 . Run BPMMi grateProf i 1 e . bat (Example 6-46) to migrate the source profile to 
the target profile. 

Example 6-46 Example of the the BPMMigrationProfile.bat command 

C:\wdpe7\bin>BPMMigrateProfile.bat -username admin -password admin 
-targetProfileName WPSCustOl -scriptCompatibil ity false 
-keepAppDi rectory false -trace fine -traceFile 
c:\MigrationSnapshot\WPSCust01\MigrationWPSCust01.trace 
c:\MigrationSnapshot\WPSCust01 WPSCustOl 


2. Examine the log files to make sure that there are no exceptions; 

- In the command output, you should find the success message shown in 
Example 6-47. 

Example 6-47 Success message for the BPMMigrationProfile command 

CWMC00822I : The BPMMi grateProf i 1 e command finished successfully. 
CWMC00850I: See the migration documentation for additional 
migration tasks that are specific to your configuration such as 
upgrading database schemas and/or running BPMMi grateCl uster 
command for clusters. 


- In the BPMProf i 1 ellpgrade log, you should see a “build successful” 
message at the end of the log. In our scenario, the file is located at: 
C:\MigrationSnapshot\WPSCust01\logs\BPMProfi 1 ellpgrade. WPSCustOl. M 
on-Apr- 19-20. 58. 54-2010. 1 og 

- In the WASPostUpgrade log, we can see a success message at the end of 
the log, as shown in Example 6-48. The log is located at: 
C:\MigrationSnapshot\WPSCust01\logs\WASPostUpgrade. WPSCustOl. Mon- 
Apr-19-20. 47. 12-2010. log 

Example 6-48 Success message in the WASPostUpgrade log file 

MIGR0271W: Migration completed successfully, with one or more 
warnings. 
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- In the BPMMi grateProf i 1 e log, we see the messages shown in 

Example 6-49 that indicate a successful migration. The log is located at: 

C:\MigrationSnapshot\WPSCust01\logs\BPMMigrateProfile.WPSCust01.M 

on-Apr-19-20.47.09-EDT-2010.log 

Example 6-49 Success message in the BPMMigrateProfile log file 

MIGR0271W: Migration completed successfully, with one or more 
warnings. 


6.5.7 Migrate the second WebSphere Process Server custom node 

For demonstration purpose, we migrate the second WebSphere Process Server 
custom node profile (WPSCust02) using the BPM profile migration wizard. 

Migrate the profile 

Migrate the profile using the BPM profile migration wizard and perform the 
following steps: 

1 . Log in to the second WebSphere Process Server custom node machine 
(saw016-sys2.itso.ral.ibm.com) using the administrator user ID. 

2. Navigate to the bi n directory under the target product installation root 
(C:\wdpe7\bin in our environment). 
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3. Run BPMMigrate.bat. The welcome window opens (Figure 6-31). Click Next. 



Figure 6-31 Welcome window of BPM profile migration wizard 
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4. Select Custom Migration as the migration type and click Next (Figure 6-32). 



Figure 6-32 Migration type selection window 
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5. The migration wizard detects our Version 6.1 .2 installation automatically 
(Figure 6-33), so we simply select it. 

If your migration wizard does not detect the source installation automatically, 
click Browse for a compatible migration source that was not detected 
and specify the source product installation root. Click Next when you finish. 



Figure 6-33 Migration source selection window 

6. The migration wizard detects the source profiles in the source installation. 
Select the one you want to migrate. Here we only have one profile to be 
migrated: 

WPSCust02, Managed [managed. wbi server] , C:\wdpe612\profiles\WPSCust02 
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Enter the administrative user ID and password for the selected profile and 
click Next (Figure 6-34). 



Figure 6-34 Migration source profile and profile type window 
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7. Specify the Snapshot™ directory and click Next. In our example, this is 
C:\MigrationSnapshots\WPSCust02 (Figure 6-35). This could be any directory 
on the machine, but as a best practice, choose a different directory than the 
source and target installation directories. 



Figure 6-35 Snapshot directory window 
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8. We enter WPSCust02 and C:\wdpe7\profiles\WPSCust02 as Target profile 
name and Target profile directory (Figure 6-36). The target profile name can 
be different from the source profile name. Click Next. 



Figure 6-36 Target profile name and directory window 
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9. In the profile migration summary window, verify the migration selections. Click 
Next to begin the migration (Figure 6-37). 



Figure 6-37 Profile migration summary window 
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10. The status of the profile migration is shown in the migration execution window 
(Figure 6-38). 



Figure 6-38 Migration execution window 

Monitor the migration to validate that it is running successfully. 
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1 1 .When the migration is finished you should see the window shown in 
Figure 6-39. Click Finish to exit. 



Figure 6-39 Migration completed window 

Migration verification 

To verify that the migration is successful, check the following logs: 

► The migration logs are located in c:\MigrationSnapshots\WPSCust02\logs. 
Examine the following logs to make sure that there are no exceptions: 

- BPMSnapshotSourceProfi le.WPSCust02.Mon-Apr-19-21.08.24-EDT-2010.log 

- WASPreUpgrade.Mon-Apr-19-21.08.31-2010.log 

- BPMCreateTargetProfi le.WPSCust02.Mon-Apr-19-21.09.45-EDT-2010.log 

- WASPostUpgrade.WPSCust02.Mon-Apr-19-21.12.20-2010.log 

- BPMProfi 1 eUpgrade.WPSCust02 .Mon-Apr-19-21 .23 .45-2010. 1 og 

- BPMMi grateProf i 1 e.WPSCust02 .Mon-Apr-19-21 . 12 . 18-EDT-2010. 1 og 
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For information about what messages to look for in the logs, refer to 6.5.6, 
“Migrate the first WebSphere Process Server custom node” on page 257 
► Check the profile creation log and the AboutThisProfile.txt file to make sure 
the profile is created successfully: 

- C:\wdpe7\l ogs\manageprof i 1 es\WPSCust02_create. 1 og 

- C:\wdpe7\profi 1 es\WPSCust02\l ogs\AboutThi sProf i 1 e.txt 


6.5.8 Migrate the first WebSphere Business Monitor custom node 

Now we migrate the first WebSphere Business Monitor custom node profile 
(WBMCustOI). All the WebSphere Dynamic Process Edition products use the 
common profile migration command-line utilities. We migrate the WBMCustOI 
profile using the command-line utilities. You can either use a GUI or the 
command-line utilities for migration. 

Create a snapshot of the source custom profile configuration 

The first step is to create the snapshot of the source WebSphere Business 
Monitor custom profile by performing the following steps: 

1 . Log in to the WebSphere Business Monitor custom node machine 

(sawOI 6-sys3.itso.ral.ibm.com in our environment) with the administrator user 
ID. 

2. Navigate to the bi n directory under target product installation root 
(C:\wdpe7\bin in our environment). 

3. Run BPMSnapshotSourceProf i 1 e . bat (Example 6-50) to copy the source 
WBMCustOI configuration files to a snapshot directory. 

Example 6-50 Example of the BPMSnapshotSourceProfile.bat command 

C:\wdpe7\bin>BPMSnapshotSourceProfile.bat -trace fine -traceFile 
c : \Mi grati onSnapshot\WBMCust01\WBMCust01Mi grati on .trace c : \wdpe612 
WBMCustOI c:\MigrationSnapshot\WBMCust01 
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4. Examine the logs under C:\MigrationSnapshot\WPSCust01\logs and make 
sure that there are no exceptions: 

- In 

BPMSnapshotSourceProfil e.WBMCustOl .Mon-Apr- 19-21 .40.22- EDT-2010. 1 
og, we can see the message shown in Example 6-51 at the end of the 
message that indicates a successful snapshot. 

Example 6-51 Success message in the BPMSnapshotSourceProifle logs 

[[4/19/10 9:40:41 PM EDT] 0 BPMSnapshotNode I main(String[] args) 
CWMC00823I : The BPMSnapshotSourceProfile command finished 
successful ly. 


- In WASPrellpgrade.Mon-Apr-19-21.40.26-2010.log, we can see the 

message shown in Example 6-52 at the end of the message that indicates 
a upgrade. 

Example 6-52 Success message in the WASPreupgrade logs 

MIGR0303I: The existing Application Server environment is save 
MIGR0420I: The first step of migration completed successfully. 


Create the target profile 

Next, create the target profile by performing the following steps: 

1. Run BPMCreateTargetProfile.bat (Example 6-53) to create the target profile. 
Example 6-53 Example of the BPMCreate Target Profile command 

C:\wdpe7\bi n>BPMCreateTargetProf i 1 e . bat -target Prof i 1 eName 
WBMCustOl -targetProfileDi rectory c:\wdpe7\profiles\WBMCust01 
-remoteMigration false c:\MigrationSnapshot\WBMCust01 
WBMCustOl 


2. Examine the command output, logs, and the AboutThisProfile.txt file listed 
in the command output. 

- At the end of the command output, we see the message indicating that the 
profile was created successfully (Example 6-54). 

Example 6-54 Success message in the command output 

CWMC00838I: The profile was created or augmented successfully. 
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- Check the BPMCreateTargetProfile log 
(C:\MigrationSnapshot\WBMCust01\logs\BPMCreateTargetProfi le.WBMCu 
st01.Mon-Apr-19-21.46.34-EDT-2010.log) and make sure that there are 
no exceptions. 

- Check the profile creation log file, 

C:\wdpe7\l ogsVnanageprof i 1 es\WBMCust01_create. 1 og, for any fatal 
profile errors. You should see the message shown in Example 6-55 if the 
profile is created successfully. 

Example 6-55 Profile creation or augmentation success message 
<message>Returning with return code: INSTCONFSUCCESS</message> 


- Check the C:\wdpe7\profi 1 es\WBMCust01\l ogs\AboutThi sProfi 1 e. txt 
file to make sure the profile is created (Example 6-56). 

Example 6-56 Content of AboutThisProfile. txt 

Application server environment to create: Custom 

Locati on : C: \wdpe7\prof i 1 es\WBMCust01 

Disk space required: 10 MB 

Profile name: WBMCustOl 

Make this profile the default: True 

Node name: WBMNodeOl 

Host name: saw016-sys3 

Federate to deployment manager: False 


Migrate the source profile to the target profile 

Next, migrate the source profile by performing the following steps: 

1 . Run BPMMi grateProf i 1 e . bat (Example 6-57) to migrate the source profile to 
the target profile. 

Example 6-57 Example of the BPMMigrationProfile.bat command 

C:\wdpe7\bin>BPMMigrateProfile.bat -username admin -password admin 
-targetProfileName WBMCustOl -scriptCompatibility false 
-keepAppDi rectory false -trace fine -traceFile 
C:\MigrationSnapshot\WBMCust01\MigrationWBMCust01.trace 
c:\MigrationSnapshot\WBMCust01 WBMCustOl 
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2. Examine the log files to make sure that there are no exceptions: 

- In the command output, you should find the “command finished 
successfully” message, as shown in Example 6-58. 

Example 6-58 Success message for the BPMMigrationProfile command 

CWMC00822I : The BPMMigrateProfile command finished successfully. 
CWMC00850I: See the migration documentation for additional 
migration tasks that are specific to your configuration such as 
upgrading database schemas and/or running BPMMigrateCl uster 
command for clusters. 


- In 

C:\MigrationSnapshot\WBMCust01\logs\BPMProfileUpgrade.WBMCust01.M 
on-Apr-19-21.55.53-2010.log, we see the “build successful” message at 
the end of the log. 

- In 

C:\MigrationSnapshot\WBMCust01\logs\WASPostUpgrade.WBMCust01. Mon- 
Apr-19-21. 52. 37-2010. log, we see the message shown in Example 6-59. 

Example 6-59 Success message in the WASPostUpgrade log file 

MIGR0271W: Migration completed successfully, with one or more 
warnings. 


C:\MigrationSnapshot\WBMCust01\logs\BPMMigrateProfile.WBMCust01.M 
on-Apr-19-21.52.35-EDT-2010.log, we see the message shown in 
Example 6-60. 

Example 6-60 Success message in the BPMMigrateProfile log file 

MIGR0271W: Migration completed successfully, with one or more 
warnings. 


6.5.9 Migrate the second WebSphere Business Monitor custom node 

Now we can migrate the second WebSphere Business Monitor custom node 
(WBMCust02). For demonstration purpose, we use the BPM profile migration 
wizard to for this profile. You can either use a GUI or command-line utilities for 
the migration. 

Perform the following steps: 

1 . Log in to the second WebSphere Business Monitor custom node machine 
(saw016-sys4.itso.ral.ibm.com) using the administrator user ID. 
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2. Navigate to the bi n directory under target product installation root 
(C:\wdpe7\bin). 

3. Run BPMMigrate.bat. The welcome window opens (Figure 6-40). Click Next. 



Figure 6-40 Welcome window of the BPM profile migration wizard 
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4. Select Custom Migration as the migration type and click Next (Figure 6-41). 



Figure 6-41 Migration type selection window 
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5. The migration wizard detected the C:\wdpe612 (WebSphere Business Monitor 
v6 . 1 .2 . 5 installation automatically (Figure 6-42), so we simply select it. If your 
migration wizard does not detect the source installation automatically, click 

Browse for a compatible migration source that was not detected and 

specify the source product installation root. Click Next when you finish. 



Figure 6-42 Migration source selection window 
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6. The migration wizard detects the source profiles in the source installation. 
Select the one you want to migrate. Here we only have one profile to be 
migrated (Figure 6-43): 

WBMCust02, Managed [wbmoni tor/managed] , C:\wdpe612\profiles\WBMCust02 
Enter the administrative user ID and password for the selected profile and 
click Next. 



Figure 6-43 Migration source profile and profile type window 
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7. Specify the Snapshot directory (C:\MigrationSnapshots\WBMCust02) and click 
Next, as shown in Figure 6-44. This could be any directory on the machine, 
but, as a best practice, choose a different directory than the source and target 
installation directory. Specify different snapshot directories for different 
profiles on the same machine. 



Figure 6-44 Snapshot directory window 
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8. We enter WBMCust02 and C:\wdpe7\profiles\WBMCust02 as the Target 
profile name and Target profile directory (Figure 6-45). The target profile 
name can be different from the source profile name. Click Next to go to the 
next window. 



Figure 6-45 Target profile name and directory window 
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9. On the profile migration summary window, verify the migration selections. 
Click Next to begin the migration (Figure 6-46). 



Figure 6-46 Profile migration summary window 
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10. The status of the profile migration will display on the migration execution 
window during migration (Figure 6-47). 



Figure 6-47 Migration execution window 

Monitor the migration to validate that it is running successfully. 
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1 1 .When the migration is finished, you should see the window shown in 
Figure 6-48. 



Figure 6-48 Migration completed window 


6.5.10 Migrate clusters 

After all the managed nodes are migrated, we can go on to migrate the clusters. 
The BPMMigrateCluster command migrates cluster-scoped applications and 
configuration information. 
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Note: 

► All the clusters must be migrated to Version 7.0 if their custom nodes have 
been migrated to Version 7.0. 

► The BPMMigrateCluster command is run under 

target_dmgr _profile_root /bin on the Version 7.0 deployment manager 
machine. 

► The deployment manager must be running during the BPMMigrateCluster 
command execution. 

► All clusters must be migrated one at a time. No simultaneous migration is 
allowed. 

► No administrative user ID and password is needed even if global security is 
enabled. 

► The BPMMigrateCluster command can be run again if a failure occurs. 


Perform the following steps: 

1 . Log in to the deployment manager machine with the administrator user ID . 

2. Navigate to the bi n directory under the target deployment manager profile 
installation root (C:\wdpe7\profiles\WDPEDmgr\bin). 

3. Issue the command as shown in Example 6-61 in order to obtain usage 
information. 

Example 6-61 Example of the bin>BPMMigrateCluster.bat -help command 

C : \wdpe7\prof i 1 es\WDPEDmgr\bi n>BPMMi grateCl uster . bat -hel p 

Usage: BPMMigrateCluster <backupDir> <cluster> <target deployment 
manager profile name> 


- <backupDir> is the migration snapshot directory. It contains the 
configuration of the source deployment manager 
(c:\MigrationSnapshot\WDPEDmgr). 

- <cluster> is the cluster name that you want to migrate (WPS. Messaging in 
our environment). 

- ctarget deployment manager profile name> is the profile name of your 
target deployment manager (WDPEDmgr in our environment). 

4. The BPMMigrateCluster command creates a log when it runs that is written to 
the following directory: 

snapshot_directory/ logs/BPMMi grateCl uster -DmgrProfileName . time_stamp 
. log 
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snapshot_directory\s the value specified for the <backupDir> parameter in 
the BPMMigrateCluster command. You can view the log file with a text editor 
after migration. 

Migrate the WPS. Messaging cluster 

We migrate the WPS.Messaging cluster by performing the following steps: 

1 . Issue the command shown in Example 6-62 to migrate the WPS.Messaging 
cluster. 

Example 6-62 Command to migrate the WPS.Messaging cluster 

C:\wdpe7\profi 1 es\WDPEDmgr\bi n>BPMMigrateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr WPS.Messaging WDPEDmgr 


2. Check the logs file in c:\MigrationSnapshot\WDPEDmgr\logs 

(BPMMigrateCl uster.WDPEDmgr.Mon-Apr-19-22.18.24-2010.log in our 
environment) for the message BUILD SUCCESSFUL and make sure that there 
are no exceptions. If an error occurred and you can determine the cause from 
the message, attempt to correct the problem and rerun the command. Even if 
you cannot determine the cause or the corrective action to take, try rerunning 
the BPMMigrateCluster command. It is safe to rerun the command multiple 
times. 

Migrate other clusters 

Follow the steps in “Migrate the WPS.Messaging cluster” on page 285 to migrate 
the other clusters, one at a time. 

Perform the following steps: 

1 . Run the commands shown in Example 6-63 to migrate the clusters. 

Example 6-63 Commands to migrate the other clusters 
C : \wdpe7\prof i 1 es\WDPEDmgr\bi n>BPMMi grateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr WPS. Support WDPEDmgr 

C:\wdpe7\profi 1 es\WDPEDmgr\bi n>BPMMi grateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr WPS.AppTarget WDPEDmgr 

C : \wdpe7\prof i 1 es\WDPEDmgr\bi n>BPMMi grateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr WBM. Support WDPEDmgr 

C:\wdpe7\profi 1 es\WDPEDmgr\bi n>BPMMi grateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr WBM.AppTarget WDPEDmgr 
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C : \wdpe7\prof i 1 es\WDPEDmgr\bi n>BPMMi grateCl uster.bat 
c:\MigrationSnapshot\WDPEDmgr BPM.WebDashboard WDPEDmgr 


2. Check the log files in the c:\MigrationSnapshot\WDPEDmgr\logs directory for 
the message BUILD SUCCESSFUL and make sure that there are no exceptions 
after migrating each cluster. If an error occurred and you can determine the 
cause from the message, attempt to correct the problem and rerun the 
command. Even if you cannot determine the cause or the corrective action to 
take, try rerunning the BPMMi grateCl uster command. It is safe to rerun the 
command multiple times. 

6.5.1 1 Back up the target environment 

After migrating all the clusters, it is a good idea to back up the migrated 

environment before you synchronize with the nodes. 

Stop the deployment manager 

Stop the deployment manager by performing the following steps: 

1 . Log in to the deployment manager machine with the administrator user ID. 

2. Open a command window and navigate to the 
c : \wdpe7\prof i 1 es\WDPEDmgr\bi n directory. 

3. EnterstopManager.bat -username admin -password admin and press Enter 
to stop the deployment manager 

4. Check the c:\wdpe7\profiles\WDPEDmgr\logs\dmgr\System0ut.log file to 
ensure that the deployment manager has stopped. 

Back up the target environment 

Back up the target environment by performing the following steps: 

1 . On the deployment machine, back up the target deployment manager 
installation folder (c:\wdpe7) by compressing it. 

2. Repeat step 1 on page 21 8 for all the other target environment installations. In 
our scenario, this was performed on machines saw016-sys1 .itso.ral.ibm.com, 
sawOI 6-sys2. itso. ral . ibm .com , saw0 1 6-sys3. itso. ral . ibm .com , 

sawOI 6-sys4.itso.ral.ibm.com. 


Note: If you created the target profile in a separate directory other than 
under the product binary directory, you should back up both the profile and 
product directories. 
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Back up the databases 

Back up the product databases and the user databases (WDPEDB in our 

scenario). 

Perform the following steps: 

1 . Log in to the machine that hosts the product databases and user databases 
(saw007-sys2.itso.ral.ibm.com). 

2. Select Start Run..., and then enter db2cmd to launch the DB2 command 
window. 

3. Execute the commands shown in Example 6-64 to back up the product 
databases and user databases. 

Example 6-64 Product databases and user databases backup 

cd c:\dbbackup 
db2 backup database WPRCSDB 
db2 backup database BPEDB 
db2 backup database OBSVRDB 
db2 backup database MEDB 
db2 backup database EVENT 
db2 backup database MONITOR 
db2 backup database BSPACEDB 
db2 backup database WDPEDB 


6.5.12 Synchronize the managed nodes 

We need to synchronize the node with the target deployment manager by 
running the syncNode command for each managed node. 


Note: 

► When executing syncNode, make sure that the target deployment manager 
is running. 

► Before running the synchronization procedure, you should back up the 
target migration environment. If the synchronization procedure fails, you 
should restore the backup and redo the synchronization. For more 
information, refer to the IBM Technote found at the following address: 

http://www.ibm.com/support/docview.wss?uid=swg2 1410474 
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If you check the installed applications under the 

target_custom _pro/ZZe_roof/instal 1 edApps/ceZ Z_name directory on the 
custom node machines 

(c : \wdpe7\prof i 1 es\WPSCust01\i nstal 1 edApps\WDPECel 1 in our environment) 
before running the synchronization, you will find that some applications, for 
example, the Failed Event Manager, are still at Version 6.1.2. 

Now we begin the synchronization by performing the following steps: 

1 . Start the target deployment manager by performing the steps in 6.5.5, “Start 
the target deployment manager” on page 257. 

2. Log in to the machine hosting the first WebSphere Process Custom node with 
the administrator user ID. 

3. Execute the syncNode command shown in Example 6-65 under 
custom _profile_root /bin. 

Example 6-65 The syncNode command 

C:\wdpe7\profi 1 es\WPSCust01\bi n>syncNode . bat 
saw007-sysl.itso.ral.ibm.com 8879 -username admin -password admin 

- saw007-sys1 .itso.ral.ibm.com is the host name of the target deployment 
manager. 

- 8879 is the SOAP_CONNECTOR_ADDRESS port of target deployment 
manager. 

- The -username admin -password admin option is the administrative user 
ID and password, which are required if global security is enabled. 

The command output is show in Example 6-66. 

Example 6-66 Command output of syncNode 

C:\wdpe7\profi 1 es\WPSCust01\bi n>syncNode. bat 
saw007-sysl.itso.ral.ibm.com 8879 -username admin -password admin 
ADMU01 161 : Tool information is being logged in file 

C : \wdpe7\prof i 1 es\WPSCust01\l ogs\syncNode. 1 og 
ADMU0128I : Starting tool with the WPSCustOl profile 
ADMU0401I: Begin syncNode operation for node WPSNodeOl with 
Deployment Manager saw007-sysl.itso.ral.ibm.com: 8879 
ADMU0016I: Synchronizing configuration between node and cell. 
ADMU0402I: The configuration for node WPSNodeOl has been 
synchronized with Deployment Manager saw007-sysl.itso.ral.ibm.com: 
8879 

4. Check the application level after synchronization. All applications should be 
Version 7.0. 
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5. Repeat steps 2 on page 288 through 4 to synchronize the other three custom 
profiles, that is, WPSCust02, WBMCustOI, and WBMCust02. 

6.5.13 Update the BPC database 

The next step is to update the BPC database. 

Generate the BPC upgrade script 

During migration, a database properties file is generated. This properties file is 
required to generate the schema upgrade scripts for the BPC database. 

Perform the following steps: 

1 . Log in to the deployment manager machine with the administrator user ID. 

2. Navigate to target _dmgr_instal l_root \ uti 1 \dbllti 1 s 
(C:\wdpe7\util\dblltils in our environment). 

3. Execute the following command to edit the BPC database schema properties 
interactively: 

C : \wdpe7\uti 1 \dbllti 1 s>DbDesi gnGenerator . bat -e 

c : \wdpe7\prof i 1 es\WDPEDmgr\dbscri pts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema. properties 

- c : \wdpe7\prof i 1 es\WDPEDmgr\dbscri pts\ProcessChoreographer\DB2\BPEDB 
\BPC\createSchema. properties specifies the BPC database schema 
properties file name. It is under 

target_dmgr _profile_root\ dbscri pts\ProcessChoreographer\DB2\BPEDB 
\BPC\. 

The command output is shown in Example 6-67. The input is highlighted in 

bold. 


Note: Enter true for Use tabl espaces if you have a separate directory for 
the BPC database. A table space directory is required when using 
tablespaces or migrate from pre-6.2 version. 


Example 6-67 Command output for editing the BPC database schema properties file 
C:\wdpe7\uti 1 \dbUti 1 s>DbDesignGenerator.bat -e 

c:\wdpe7\profiles\WDPEDmgr\dbscripts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema . properties 

[info] running DbDesi gnGenerator in editing mode... 

[info] analyzing the database design ... 
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[status] BPC is not complete with 1 remaining item(s): 

[ 1 ] BPC : : dbProviderKey is not set. 

[info] Please pick one of the following [database type(s)] : 

(1) DB2-distributed 

(2) DB2-iSeries 

(3) DB2-zOS-8 

(4) DB2-zOS-9 

(5) Derby 

(6) Informix 

(7) 0racle 

(8) SQL Server 

Please enter the number for the database type 
[default=DB2-distributed] :1 

[info] Please enter the values for the properties in the database 
objects section. 

[info] Please pick one of the following [scenario(s)] : 

(1) Configuration 

(2) Migration 

(3) Removal 

Please enter the number for the scenario [default=Configuration] :2 
Database name[default=BPEDB] : 

Territory (only needed when creating the database) [defaul t=en-us] : 
Database schema name (leave empty to use default schema / implicit 
schema) [defaul t=BPC] : 

Use tablespaces (true/false)? [defaul t=false] :true 
Tablespace directory / container path (only needed when using 
tablespaces or when migrating from a pre-6.2 release; use file 
separator appropriate for the database server) [defaul t=] 

:c:\DBTablespace 

Tablespace for audit log items (leave default when not using 
tablespaces) [defaul t=AUDITLOG] : 

Tablespace for instance items (leave default when not using 
tablespaces) [defaul t=INSTANCE] : 

Tablespace for scheduler items (leave default when not using 
tablespaces) [defaul t=SCHEDTS] : 

Tablespace for staff query items (leave default when not using 
tablespaces) [defaul t=STAFFQRY] : 
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Tabplespace for template items (leave default when not using 
tablespaces) [defaul t=TEMPLATE] : 

Tablespace for work item tables and indexes (leave default when not 
using tabl espaces) [defaul t=WORKITEM] : 

[info] You have completed database objects section properties needed 
for database scripts generation. 

To skip data source properties, enter 's'; or enter anything else to 
continue :s 

[info] data source properties section is skipped. 

Do you want to save changes back to the same file 
' c : \wdpe7\prof i 1 es\WDPEDmgr\dbscri pts\ProcessChoreographer\DB2\BPEDB 
\BPC\createSchema. properties'? (y/n) :y 

[info] The database design has been generated in 
c : \wdpe7\prof i 1 es\WDPEDmgr\dbscri pts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema. properties 
[info] thanks, quitting now ... 


4. Execute the command in Example 6-68 to generate the BPC database 
upgrade scripts. 

Example 6-68 Generate the BPEDB update script command 
C:\wdpe7\uti 1 \dbllti 1 s>DbDesignGenerator.bat -g 

c:\wdpe7\profi les\WDPEDmgr\dbscripts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema . properties 


The command output is shown in Example 6-69. The scripts generated in the 
directory are highlighted in bold. 

Example 6-69 The command output to generate the BPEDB update script 
C:\wdpe7\uti 1 \dbllti 1 s>DbDesignGenerator.bat -g 

c:\wdpe7\profi les\WDPEDmgr\dbscripts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema . properties 

[info] running DbDesignGenerator in generating mode... 

[info] generating database scripts from 

c:\wdpe7\profi les\WDPEDmgr\dbscripts\ProcessChoreographer\DB2\BPEDB\ 
BPC\createSchema . properties 
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[info] The script(s) have been generated in 

C:\wdpe7\util\dblltils\DB2-distributed-BPC 

[info] thanks, quitting now ... 


Update the BPC database schema 

Perform the following steps to update BPC database schema: 

1 . To upgrade BPC database schema, copy the entire 
C:\wdpe7\uti 1 \dbllti 1 s\DB2-di stri buted-BPC folder from the target 
deployment manager system to c:\saw016\V7.0 on the DB2 system. 

2. Log in to the database system with the db2admin user ID. 

3. Open a DB2 command prompt and change to the db2scripts directory: 
cd c:\saw016W7.0\DB2-distributed-BPC 

4. We use the command in Example 6-70 to upgrade the BPC database 
schema. Make sure each SQL statement is executed successfully. 

Example 6-70 Example of the upgrade monitor schema command 

C:\saw016\V7.0\DB2-di stri buted-BPC>db2 connect to BPEDB user 
db2admin using password 

C:\saw016\V7.0\DB2-di stri buted-BPC>db2 -tvf upgradeTablespace612.sql 
C:\saw016\V7 . 0\DB2-di stri buted-BPC>db2 -tvf upgradeSchema612 . sql 
C:\saw016\V7. 0\DB2-di stri buted-BPC>db2 connect reset 


Migrate the BPC data 

When migrating from a pre- Version 6.2 product, a data migration must be done 
before you start the server or any cluster member that has BPC configured. The 
data migration is done by running the migrateDB.py script. 


Note: 

► The migrateDB.py script must be run from the node that hosts the BPC 
cluster member or server. 

► If there are multiple BPC clusters configured, this script must be run 
against each BPC database. 


1 . Log in to the machine that hosts one member of the WPS.AppTarget cluster 
with the administrator user ID. The BPC container is deployed to the 
WPS.AppTarget cluster. 

2. Navigate to target _WPS_custom jrofilejrootVotn 
(C : \wdpe7\prof i 1 es\WPSCust01\bi n in our example). 
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3. Execute the command in Example 6-71 to migrate the BPC data. 

Note: The conntype should be NONE. 

Example 6-71 Migrate BPC data 

C:\wdpe7\profiles\WPSCust01\bin>wsadmin.bat -conntype NONE 
-profit eName WPSCustOl -tracefile 

c:\MigrationSnapshot\WPSCust01\logs\migrateDB.trace -f 
c:\wdpe\ProcessChoreographer\admin\migrateDB.py -cluster 
WPS.AppTarget -dbUser db2admin -dbPassword password 

- Specify NONE as the connect type using -conntype NONE. 

- -profileName WPSCustOl specifies the custom profile of this WebSphere 
Process Server node. 

- -tracefile c:\MigrationSnapshot\WPSCust01\logs\migrateDB.trace 
specifies the trace file. 

- -f c:\wdpe\ProcessChoreographer\admin\migrateDB.py specifies the 
migrateDB.py location. The script is located in 

WPS_instal Z_root\ProcessChoreographer\admi n\. 

- -cluster WPS.AppTarget specifies the cluster name where the BPC 
container is deployed. 

- -dbUser db2admin -dbPassword password is the DB2 administrative user 
ID and password. 

The command output is shown in Example 6-72. 

Example 6-72 Command output of migrating BPC data 

C:\wdpe7\profiles\WPSCust01\bin>wsadmin.bat -conntype NONE -profileName 
WPSCustOl -tracefile 

c:\MigrationSnapshot\WPSCust01\l ogs\mi grateDB. trace -f 
c : \wdpe7\ProcessChoreographer\admi n\mi grateDB. py -cl uster WPS.AppTarget 
-dbUser db2admin -dbPassword password 

WASX7357I: By request, this scripting client is not connected to any 
server process. Certain configuration and application operations will 
be available in local mode. 

WASX7303I: The following options are passed to the scripting 
environment and are available as arguments that are stored in the argv 
variable: "[-cluster, WPS.AppTarget, -dbUser, db2admin, -dbPassword, 
password] " 

Using configured schema qualifier 'BPC 1 . 
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File C:\wdpe7\universalDriver_wbi\lib\db2jcc.jar exists, adding it to 
the classpath. 

File C:\wdpe7\universalDriver\lib\db2jcc_license_cu.jar exists, adding 
it to the classpath. 

Fi le C:\wdpe7\universal Dri ver_wbi\l ib\db2jcc_l icense_cisuz. jar exists, 
adding it to the classpath. 
migrateDB.py finished. 


6.5.14 Migrate the BPC Observer (optional) 

The source BPC Observer can still work even after the environment is migrated 
to Version 7.0. You can still log in to the BPC Observer using 
https:/ /hostname :default_secure _porf /bpcobserver, but if you want to view 
the report in BPC Explorer, you need to migrate it to Version 7.0. 


Note: 

► Migrate BPC Observer if you want to use the new feature. 

► Do not migrate BPC Observer if any profile that hosts BPC Explorer is not 
migrated. 


To migrate the BPC Observer, perform the following steps: 

1 . Log in to the machine that hosts deployment manager with the administrator 
user ID. 

2. Navigate to targe t_dmgr _profile_root/bin 
(C:\wdpe7\profiles\WDPEDmgr\bin in our example). 

3. Execute the following command to migrate the BPC Observer: 
C:\wdpe7\profiles\WDPEDmgr\bin>wsadmin.bat -conntype NONE -f 
. . \ProcessChoreographer\mi grate_BPCObserver_WPS . Support . jacl 
The command output is shown in Example 6-73. 

Example 6-73 Command output for migrating the BPC Observer 

C:\wdpe7\profiles\WDPEDmgr\bin>wsadmin.bat -conntype NONE -f 
. .\ProcessChoreographer\migrate_BPCObserver_WPS. Support .jacl 

WASX7357I: By request, this scripting client is not connected to any 
server process. Certain configuration and application operations 
will be available in local mode. 

Updated BPCExplorer_WPS. Support. 

Now uninstall BPCObserver_WPS. Support using the administrative 
console. 
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4. You can either uninstall the old BPC Observer from the administrative console 
or leave it there. 

6.5.15 Migrate the Alphablox repository 

The Alphablox repository of our source environment is in the same database as 
the WebSphere Business Monitor database, but it uses DB2ADMIN as the 
schema instead of MONITOR. As a result, Alphablox repository migration is 
needed. 


Note: 

► You should stop all servers that are running Alphablox applications before 
migration. 

► The deployment manager should be running during migration. 

► If your existing database repository is in the same database as the 
WebSphere Business Monitor database and is using the same schema as 
the MONITOR metadata tables, then migration to Version 7.0 is not 
necessary. 


Perform the following steps: 

1 . Stop the target deployment manager and back up the whole target runtime 
environment as well as the database by following the steps in 6.5.1 1 , “Back 
up the target environment” on page 286. 

Note: Before migrating the Alphablox repository, back up the whole target 
environment. You might need to recover the environment if you get any 
errors during the Alphablox repository migration. 

2. Start the target deployment manager by following the steps in 6.5.5, “Start the 
target deployment manager” on page 257. 

Note: The target deployment manager must be started before migrating 
the Alphablox repository, or it will fail. 

3. Log in to one of the machines where Alphablox is installed 

(sawOI 6-sys3.itso.ral.ibm.com in our environment) with the administrator user 
ID. 

4. Open a command line and navigate to target J\lphablox_install_rootl bin 
(C:\wdpe7\Alphablox\bin in our environment). 
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5. Run the convertRepository.bat command to migrate the Alphablox 

repository interactively. The command output is shown in Example 6-74 (The 
input is highlighted in bold). For more details, refer to the Information Center 
topic at the following address: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm . btool s . hel p .moni tor .mi g . doc/mi g/62_to_n_abx_db_db_cpy61 . html 

Note: Remember to set the IBM Alphablox file manager root and instance 
name before converting one repository to another. In Example 6-74, we 
first choose 1 and 2 to set the manager root and instance name. Finally, we 
choose 3 to convert one repository to another. 


Example 6-74 Execute convertRepostiory.bat interactively 
C:\wdpe7\Al phabl ox\bi n>ConvertReposi tory . bat 


- note: 

- To have this utility use JDBC drivers for a non - 

- DB2 database, update the ConvertReposi tory. lax 

- file. Add the needed drivers jars to the 

- "lax. class. path" property. 


Press any key to continue . . . 

IBM Alphablox Repository Conversion Utility 9. 5. 0.0 Build 262 
[Interim Fix] 

Copyright International Business Machines Corporation 2007. All 
rights reserved. 

US Government Users Restricted Rights - Use, duplication or 
disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 

A MSSQL 2005 Driver was not found in the classpath; MSSQL 2005 
connectivity disabled 

An Oracle Driver was not found in the classpath; Oracle connectivity 
disabled 

An Informix JDBC Driver was not found in the classpath; Informix 
connectivity disabled 

Please choose an option: 

1) Set IBM Alphablox File Manager root 

2) Set IBM Alphablox instance name 
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3) Convert one repository to another 

4) Create an empty database repository 

5) Verify and repair a repository 

6) Change IBM Alphablox to use a different repository 

7) Conversion Utility options 

8) Configure Web Application Server Connection pooling 

9) Exit 

Select (1-9): 1 

Enter new File Manager root [] : c:\wdpe7\Alphablox\repository 
Please choose an option: 

1) Set IBM Alphablox File Manager root 
[c : \wdpe7\Al phabl ox\reposi tory\] 

2) Set IBM Alphablox instance name 

3) Convert one repository to another 

4) Create an empty database repository 

5) Verify and repair a repository 

6) Change IBM Alphablox to use a different repository 

7) Conversion Utility options 

8) Configure Web Application Server Connection pooling 

9) Exit 

Select (1-9): 2 

Enter new instance name [] : AlphabloxAnalytics 
Please choose an option: 

1) Set IBM Alphablox File Manager root 
[c : \wdpe7\Al phabl ox\reposi tory\] 

2) Set IBM Alphablox instance name [AlphabloxAnalytics] 

3) Convert one repository to another 

4) Create an empty database repository 

5) Verify and repair a repository 

6) Change IBM Alphablox to use a different repository 

7) Conversion Utility options 

8) Configure Web Application Server Connection pooling 

9) Exit 

Select (1-9): 3 
Please choose an option: 

1) Convert from file to database 

2) Convert from database to file 
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3) Convert from file to file 

4) Convert from database to database 

5) Go back to main menu 

Select (1-5): 4 


Convert Database To Database 
Source Database 

Please select the database type: 

1) IBM DB2 

2) Apache Derby Server 

3) Go back to main menu 

Select (1-3): 1 

Server: saw007-sys2.itso.ral .ibm.com 
Port []: 50000 
Alias []: MONITOR 

Schema (if different from user): DB2ADMIN 
User: db2admin 
Password: password 

1) Continue, 2) Re-enter, 3) Go back to main menu Select (1-3): 1 

Convert Database To Database 
Destination Database 

Please select the database type: 

1) IBM DB2 

2) Apache Derby Server 

3) Go back to main menu 

Select (1-3): 1 

Server: saw007-sys2.itso.ral .ibm.com 
Port []: 50000 
Alias []: MONITOR 

Schema (if different from user): MONITOR 
User: db2admin 
Password: password 
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1) Continue, 2) Re-enter, 3) Go back to main menu Select (1-3): 1 


The following questions can be answered by using the first character 
in the selected option or press <ENTER> for the default. 

Enter conversion operation (COPY, MOVE) [COPY]: COPY 

Enter repository creation operation (NEW, UPDATE, OVERWRITE) [NEW]: 

OVERWRITE 

Update IBM Alphablox to use the destination repository [Y] : Y 
Update IBM Alphablox properties in the destination 
repository (ALL, SPECIFIC, GLOBAL, NONE) [ALL]: ALL 

Below is a description of the options selected: 

* Copy source repository to destination repository. Remove existing 
destination repository before copying (if it exists). 

* Set Alphablox to point to the destination repository. 

* Copy all Alphablox server properties to the destination 
repository. 

1) Continue, 2) Re-enter, 3) Go back to main menu Select (1-3): 1 
Deleting existing repository... 

Creating the destination repository... 

Copying the source repository (this may take a few minutes)... 
Updating the server to point to the destination repository... 

Could not test for running server: Could not find Tel netConsolePort 
number 

Do you want to move source Cluster Manager settings to the 
destination (Y/N) [Y] : Y 

Found previous connection pooling data source in server. properties; 
Using it. 

Repository operation completed successfully 
Please choose an option: 

1) Set IBM Alphablox File Manager root 
[c : \wdpe7\Al phabl ox\reposi tory\] 

2) Set IBM Alphablox instance name [A1 phabl oxAnalyti cs] 

3) Convert one repository to another 

4) Create an empty database repository 

5) Verify and repair a repository 

6) Change IBM Alphablox to use a different repository 

7) Conversion Utility options 
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8) Configure Web Application Server Connection pooling 

9) Exit 

Select (1-9): 9 
C:\wdpe7\Al phabl ox\bi n> 


6.5.16 Migrate Business Space 

Next, we migrate Business Space. The tasks described in this section must be 
done in the listed sequence. You must start and stop the deployment manager, 
node agents and servers exactly as the instructions in this section indicate. 

Update the Business Space schema 

Before updating the Business Space schema, stop the deployment manager by 
performing the following steps: 

1 . Stop the target deployment manager by following the steps in “Stop the 
deployment manager” on page 286. 

2. To upgrade the Business Space database schema, copy the entire 
target_dmgr _profile_root \dbscri pts\BusinessSpace folder from the target 
deployment manager system to c:\saw016\V7.0 on the DB2 system. 

3. Log in to the database system as the db2admin user. 

4. Open a DB2 command prompt and change to the dbscripts directory: 
cd C:\saw016\V7.0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB 

5. We use the following command to upgrade the Business Space database 
schema. Enter the database administrative user ID (db2admin) and password 
when prompted for them. Make sure each SQL statement is executed 
successfully: 

C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>migrateSc 
hema.bat 

6. Tun the bind command for BSPACEDB, as shown in Example 6-75. 

Example 6-75 Run the rebind command for BSPACEDB 

C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2 

connect to BSPACEDB user db2admin using password 
C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2 bind 
c:\IBM\DB295\bnd\edb2cli.lst blocking all grant public 
C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2 bind 
c:\IBM\DB295\bnd\0db2ubind.lst blocking all grant public 
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C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2 

connect reset 

C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2stop 
04/21/2010 13:22:19 0 0 SQL1064N DB2ST0P processing was 

successful . 

SQL1064N DB2ST0P processing was successful. 

C:\saw016W7. 0\BusinessSpace\BPM.WebDashboard\DB2\BSPACEDB>db2start 
04/21/2010 13:22:24 0 0 SQL1063N DB2START processing was 

successful . 

SQL1063N DB2START processing was successful. 


Install the WebSphere Process Server product widget 

Because the machine hosting Business Space does not have WebSphere 
Process Server installed on it, we need to manually install the WebSphere 
Process Server widget on the cluster where Business Space is running (the 
BPM.WebDashboard cluster in our environment). 


Note: In Version 7.0, product widgets are shipped with the separate Business 
Process Management products instead of a Business Space product. In our 
topology, we did not install WebSphere Process Server on the machines that 
host Business Space (saw016-sys3.itso.ral.ibm.com and 
saw016-sys4.itso.ral.ibm.com), so we need to install the WebSphere Process 
Server widgets manually. 


Perform the following steps: 

1 . Log in to the target deployment manager machine with the administrator user 
ID. 

2. Start the target deployment manager. 

3. Open a command line and navigate to target _dmgr _profi lejroot \bi n. 
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4. Run the commands shown in Example 6-76 (highlighted in bold). 

Example 6-76 Install widget command 

C:\wdpe7\profiles\WDPEDmgr\bin>wsadmin.bat -username admin -password 
admin 

WASX7209I: Connected to process "dmgr" on node WDPECel IManager using 
SOAP connector; The type of process is: DeploymentManager 
WASX7029I: For help, enter: "$Help help" 

wsadmi n>$AdminTask install BusinessSpaceWidgets {-cl usterName 
BPM.WebDashboard -widgets c:\wdpe7\BusinessSpace\widgets\WPS} 

wsadmi n>quit 


- -clusterName BPM.WebDashboard specifies the cluster name where 
Business Space is deployed. 

- -widgets c:\wdpe7\BusinessSpace\widgets\WPS is the WebSphere 
Process Server widgets location, as shown in Figure 6-49. All the products 
widgets are located in product_instal Z_roof \BusinessSpace\widgets. 


Address |£3) C:\wdpe7\BusinessSpace\widgets\WPS 


Folders 

E £3) updi 
B Q wdpe7 

E Q Alphablox 
E £3) AppScheduler 
E Si bln 
E £3) bpm 


(PIWidgets_BusinessRutes.zip I 

(Ll WidgetsJHumanT askManagementWidgets . zip 


E Si config.bspace 
E £3) mm.config 
E £3) mm. runtime 
E £3) profileTemplates 
B registryData 
E £3) scripts 
B £3) widgets 
£3|CORE 
Si wbm 
Si wesb 

Swps 


Figure 6-49 WebSphere Process Server widgets 
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5. After installing the WebSphere Process Server widgets, you can check the 
following location to ensure that the WebSphere Process Server widgets are 
there: 

target_dmgr _pro/iZe_roo£\BusinessSpace\cZus£er_name\widgets 
In our example, shown in Figure 6-50, the widgets are in the following 
location: 

C:\wdpe7\profiles\WDPEDmgr\BusinessSpace\BPM.WebDashbaord\widgets 


Address |q C:\wdpe7\profiles\WDPEDmgr\BusinessSpace\BPM.WebDashboard\widgets 

Folders 

X 

B S> profiles 

B S) WDPEDmgr 
Si bin 

B Q BusinessSpace 

B S) BPM . WebDashboard 
El Si mm. runtime. prof 

b s BSSSSl 

m E3) install. Apr-19-22. 36. 58-EDT-2010 

A 

B Q installw. Apr-2 1 - 13 .32 .22-EDT-20 1 0 
El Si Widgets_BusinessRules 
El Widgets HumanTaskManaqementWidqets 


Figure 6-50 Installed WebSphere Process Server widgets 


6. Start all the node agents. 

7. From the deployment manager machine, open the properties file at: 

target _dmgr _profile_root\BusinessS<pace\Business_Space_Cluster_Name\m 
m. runtime . prof \conf i g\Conf i gServi ce . properties 
For example: 

C : \wdpe7\prof i 1 es\WDPEDmgr\Busi nessSpace\BPM .WebDashboard . WBMNodeOl . 
0\m. runtime. prof \confi g\Confi gServi ce . properti es 

8. Search the file for the com. ibm.mashups. directory, templates entry. The 
value is shown in Example 6-77. 

Example 6-77 The value of com.ibm.mashups.directory.templates 
com. ibm.mashups. directory. templates = 

conf i g/cel 1 s/WDPECel 1 /nodes/fi IBMNodeOl /servers /BPM. WebDashboard. WBMNo 
deOl . 0/mm/templ ates 


From the this value, we can identify the following information: 

- Node name: WBMNodeOl 

- Server name: BPM.WebDashboard.WBMNodeOl.O 
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9. We need to start the BPM.WebDashboard.WBMNodeOI .0 server. On the 
administrative console, navigate to Servers — > Server Types -» WebSphere 
application servers, select BPM.WebDashboard.WBMNodeOI .0, and click 
Start. 

This will populate the configuration from the deployment manager to the 
BPM.WebDashboard.WBMNodeOI .0 server. You should now be able to find 
the BPM.WebDashboard folder in 

C:\wdpe7\profiles\WBMCust01\BusinessSpace, as shown in Figure 6-51. 


Address |l£) C:\wdpe7\profiles\WBMCust01\BusinessSpace 

Folders 

X 

Name 

B profiles 

□ Si WBMCustOl 
& bin 

b c-t ^§Q33£2£9I 

El £j) BPM.WebDashboard 
B ED datamigration 
£l widgets 

- 

tj)BPM. WebDashboard 


O datamigration 


Figure 6-5 1 BPM. WebDashboard folder 


10. Stop the BPM.WebDashboard.WBMNodeOI .0 server from the administrative 
console. 

1 1 .Log in to the machine that hosts the identified node (WBMNodeOI). 

12. Open 

identified_custom _pro/iZe\BusinessSpace\BPM.WebDashboard\mm.runtiine. 
prof \publ i c\ oobLoadedStatus . properties with a text editor, for example 
C:\wdpe7\profi 1 es\WBMCust01\Bus i nessSpace\BPM. WebDashboard\mm. runt im 
e.prof\public\oobLoadedStatus. properties in our environment. 

13. Update the importTemplates.txt and importSpaces.txt properties to true, as 
shown in Example 6-78. 

Example 6-78 Updated properties in oobLoadedStatus.properties 

importTemplates.txt=true 

importSpaces.txt=true 


14.0n the administrative console, navigate to System administration -> 
Nodes. Select all the nodes, then click Full Resynchronize to synchronize 
the custom profile. 
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Copy the iwidget files 

During profile migration, the Version 6.2.0 and Version 6.1.2 widget definition 
files are automatically copied to the following directory on the Version 7.0 target 
server that hosts Business Space: 
profi le_root /Busi nessSpace/datami grati on/wi dgets 

However, the Version 7.0 widget definition files and any Version 6.2.0 or 
Version 6.1 .2 custom widget definition files must be copied to this directory 
manually. 

For a clustered Business Space environment, copy the widget files on all the 
profiles participating in the cluster by performing the following steps: 

1 . Log in to one of the machines where Business Space is installed with the 
administrator user ID. 

2. Search all the iwidget.xml files under the 

pro/i Ze_root\instal 1 edApps\CeZ ZJVame directory 

(C : \wdpe7\prof i 1 es\WBMCust01\i nstal 1 edApps\WDPECel 1 in our example). 

3. Copy all of the iwidget.xml files you find to the 
profilejroot \ Busi nessSpace\datami grati on\wi dgets directory 

(C : \wdpe7\prof i 1 es\WBMCust01\Busi nessSpace\datami grati on\wi dgets in 
our example) on the machines where the Business Space is installed. 
Overwrite the existing files if there are any. 

4. Follow steps 1 - 3 to copy the i wi dget . xml files to the 
pro/iZe_roof\BusinessSpace\datamigration\widgets directory on all the 
other machines that host Business Space. 

Migrate the Business Space data 

When migrating the Business Space data, the personalized information that is 
migrated for every Business Space user is limited to 10 of the most recently 
viewed pages and 60 of the most recently adjusted widgets. 

Before migrating the Business Space data, the target deployment manager and 
at least one of the node agents and servers that host Business Space should be 
started. 

To migrate the Business Space data, perform the following steps: 

1 . Start the application server that hosts the Business Space Manager 
applications (BPM.WebDashboard.WBMNodeOl.O). On the administrative 
console, click Servers -» Application Servers, select 
BPM.WebDashboard.NodeOl.O, and click Start. 

2. Log in to the machine where the started application server in step 1 is 
running. 
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3. Open a command line window and navigate to 

target _custom_node _install _root\ BusinessSpace\scripts 
(C:\wdpe7\BusinessSpace\scripts in our environment). 

4. Execute the following command: 

C:\wdpe7\BusinessSpace\scripts>mi grateBSpaceData.bat -host 
saw016-sys3.itso.ral.ibm.com -port 8881 -user admin -password admin 
-cluster BPM.WebDashboard 

- -host saw016-sys3.itso.ral.ibm.com is the host name of the machine 
where the BPM.WebDashboard. NodeOI .0 server is. 

- -port 8881 is the SOAP_CONNECTOR_ADDRESS port of the 
BPM.WebDashboard. NodeOI .0 server. 

- -user admin -password admin is the administrative user ID and password. 

- -cluster BPM.WebDashboard is the cluster name where Business Space 
is running. 

The command output is shown in Example 6-79. 

Example 6-79 Command output for migrateBSpaceData.bat 

C:\wdpe7\BusinessSpace\scri pts>mi grateBSpaceData . bat -host 
saw016-sys3.itso.ral.ibm.com -port 8881 -user admin -password admin 
-cluster BPM.WebDashboard 

Starting migration, please check log file 
C:\wdpe7\l ogs\bspace\Busi nessSpaceData 

Migration.log to make sure migration was successful without any 
exception after it's completed. 

WASX7209I : Connected to process "BPM.WebDashboard. WBMNodeOl.O" on 
node WBMNodeOl using SOAP connector; The type of process is: 
ManagedProcess 

WASX7303I: The following options are passed to the scripting 
environment and are available as arguments that are stored in the 
argv variable: "[BPM.WebDashboard]" 

Business Space Data Migration was completed! 


5. Check profi le_root\ 1 ogs\cZuster_member\SystemOut . 1 og 

(C:\wdpe7\profiles\WBMCust01\logs\BPM.WebDashboard.WBMNode01.0\Syste 
mOut . 1 og in our environment) to verify the migration result. You should see the 
information shown in Example 6-80 in the logs. 

Example 6-80 DataMigrationCommand message 
DataMigration I 

com. ibm.bspace.datamigrati on. admintask. DataMigrationCommand 
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executeDBDataMigrate() Migration of Business Space v6 to V 7.0 was 
successful ! 


Migrate the widget endpoints for product and custom widgets 

If you are migrating a network deployment environment, run the 
updateBusinessSpaceWidgets command on the deployment manager profile to 
populate the migrated widget endpoints for both product and custom widgets that 
were generated in XML format under the 
profi le_root /Bus i nessSpace/datami grati on/endpoi nts folder. 

Perform the following steps: 

1 . Log in to the target deployment manager machine with the administrator user 
ID. 

2. Open a command line window and navigate to 

target _dmgr _profile_root\bir\ (C:\wdpe7\profiles\WDPEDmgr\bin in our 
environment). 

3. Execute the command shown in Example 6-81 (highlighted in bold) to update 
the Business Space widgets. 

Example 6-81 Update the Business Space widget command 

C:\wdpe7\profiles\WDPEDmgr\bin>wsadmin.bat -username admin -password 
admin 

WASX7209I: Connected to process "dmgr" on node WDPECel IManager using 
SOAP connector; The type of process is: DeploymentManager 
WASX7029I: For help, enter: "$Help help" 
wsadmi n>$AdminTask updateBusinessSpaceWidgets {-clusterName 
BPM.WebDashboard -endpoints 

c : \wdpe7\prof i 1 es\WBMCust01\Busi nessSpace\datami grati on\endpoi nts} 
wsadmi n>quit 


- -clusterName BPM.WebDashboard is the name of the cluster that hosts 
Business Space. 

- -endpoints 

c:\wdpe7\profiles\WBMCust01\BusinessSpace\datamigration\endpointsis 
the endpoint location. It is located under 

custom _pro/iZe_root\BusinessSpace\datamigration\endpoints. 

Next, you need to modify the properties in oobLoadedStatus.properties again 
after you update the Business Space widgets. 
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4. From the deployment manager machine, open the 

target _dmgr _profile_root\Bus : \nessS<pace\Business_Space_Cluster_Name\m 
m. runtime . prof \conf i g\Conf i gServi ce . properties file: 

C:\wdpe7\profi les\WDPEDmgr\BusinessSpace\BPM.WebDashboard.WBMNode01. 
0\m. runtime. prof \confi g\Confi gServi ce . properti es 

5. Search for com.ibm.mashups.directory.templates; its value is shown in 
Example 6-82. 

Example 6-82 The value of com.ibm.mashups.directory.templates 
com. ibm.mashups. directory. templates = 

config/cel ls/WDPECel 1 /nodes/(7B/WodeOi/servers/BPM.WebDashboard.(7B/Wo 
deOl . 0/mm/templ ates 

From this value, we can identify the following information: 

- Node name: WBMNodeOI 

- Server name: BPM.WebDashboard.WBMNodeOl.O 

6. Start the BPM.WebDashboard.WBMNodeOI .0 server from the administrative 
console to populate the configuration from deployment manager to the 
BPM.WebDashboard.WBMNodeOI .0 server. 

7. Stop the BPM.WebDashboard.WBMNodeOI .0 server from the administrative 
console. 

8. Log in to the machine that hosts the identified node WBMNodeOI . Open 
identified_custom _pro/iZe\BusinessSpace\BPM.WebDashboard\mm.runtime. 
prof \publ i c\ oobLoadedStatus . properties by using a text editor: 

C:\wdpe7\profi 1 es\WBMCust01\Bus inessSpace\BPM. WebDashboard\mm. runt im 
e. prof \publ i c\oobLoadedStatus . properties 

9. Update the importTemplates.txt and importSpaces.txt properties, as shown in 
Example 6-83. 

Example 6-83 Updated properties in oobLoadedStatus.properties 

importTemplates.txt=true 

importSpaces.txt=true 


10. On the administrative console, navigate to System administration ->• 
Nodes. Select all the nodes. Click Full Resynchronize to synchronize the 
custom profile. 
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6.5.17 Deploy WebSphere Business Monitor scheduled service 


In a stand-alone installation, the WebSphere Business Monitor scheduled 
services will be deployed during migration. In a network deployment 
environment, migration requires that you deploy the WebSphere Business 
Monitor scheduled services manually. Deploying the WebSphere Business 
Monitor scheduled services creates the WebSphere Application Server 
scheduler resource that calls the Data Memory System (DMS) and KPI history 
and prediction for each model. 

To deploy the WebSphere Business Monitor scheduled services in an network 
deployment environment, perform the following steps. 

1 . Stop the BPM.WebDashboard.WBMNodeOI .0 server. 

2. Make sure all the custom node agents are started (the WPSCustOI , 
WPSCust02, WBMCustOI and WBMCust02 nodes). 

3. Log in to the administrative console using an administrative user ID. 

4. Select Servers -» WebSphere Business Monitor configuration (see 
Figure 6-52). 


i Address |g) https://saw007-sysl.itso.ral 

Integrated Solutions Console Welcome 

I View: [ All tasks 
■ Welcome 
El Guided Activities 
□ Servers 

■ New server 
El Server Types 
El Clusters 

■ Deployment Environments 

El DataPower 
El Core Groups 

I b WebSphere Business Monitor I 

: :■ r ■'n:i | 

□ Applications 

b New Application 

Figure 6-52 Navigate to WebSphere Business Monitor configuration 
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5. You can see that the WebSphere Business Monitor scheduled services are 
not configured, as shown in Figure 6-53. 


om:9043/ibm/consote/login.do?actbn=secure 


in Help l Logout 


Configure WebSphere Business Monitor 


To view the details of a component or to modify a configuration, click the 
component name. 


Required components: 

Ail components must display a green check mark for your WebSphere Business 
Monitor environment to work properly. 



Component 

Status 

© 

Outbound CEI event service 


□ 

Messaging engine 

Deployed on WPS. Messaging 

□ 

Action services 

Deployed on WBM. Support 

© 

Monitor scheduled services 

Not configured 


Figure 6-53 WebSphere Business Monitor scheduled services configuration status 
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6. Click Monitor scheduled services and select WBM. Support for the cluster to 
deploy the WebSphere Business Monitor scheduled service, as shown in 
Figure 6-54. 



Figure 6-54 Select the cluster to deploy 
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7. Click Deploy Monitor Scheduled Services, as shown in Figure 6-55. 



Figure 6-55 Deploy Monitor Scheduled Services 


312 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 


8. The CWMTW0651 1 message will be displayed if the deployment is 
successful, as shown in Figure 6-56. 





w 

essaaes 


0- CWMTW0651I: The Monitor scheduled services have 
been successfully deployed on WBM. Support. 



Configure WebSphere Business Monitor > Monitor Scheduled Services 


You must install the Monitor scheduled services application to schedule recurring 
services, such as the data movement service and the key performance indicator 
(KPI) history for monitor models. 


Monitor Scheduled Services 

Status of the Monitor scheduled services: 
Deployed on WBM. Support 


Applications 

■ Enterprise 
applications 


Figure 6-56 CWMTW0651 1 message 


9. Save your workspace changes to the master configuration. Remember to 
check Synchronize changes with Nodes before clicking Save, as shown in 
Figure 6-57. 



Figure 6-57 Save to the master configuration 
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Now the list of WebSphere Business Monitor components shows that the 
“Monitor scheduled services” component is deployed on the WBM. Support 
cluster (Figure 6-58). 


Confiqure WebSphere Business Monitor 

To view the details of a component or to modify a configuration, click the 
component name. 


Required components: 

All components must display a green check mark for your WebSphere Business 
Monitor environment to work properly. 






, 

Component 








uumouno u=i event service 



Messaainq engine 

Deployed on WPS. Messaging 



Action services 

Deployed on WBM.Support 


E 

Monitor scheduled services Deployed on WBM.Support 

Optional components: 

To configure an optional component, click the component name. Components that 
are already configured display a green check mark. 



Component 

Status 


□ 

Alphablox 

Deployed on BPM.WebDashboard 


□ 

Dashboards for mobile devices 

Deployed on BPM.WebDashboard 



Inbound event emitter services fJMS 

Not configured 


o 

and REST1 


Figure 6-58 Monitor scheduled services are deployed on WBM.Support 


Errors?: If, after migration, you find that the outbound CEI event service has 
the state shown in Figure 6-58 (a red circle with an x), refer to 6.7.1 , “Update 
the outbound CEI event service” on page 329. The correct status should be 
“Configured using the event service on WPS.Support”. 


6.5.18 Update the WebSphere Business Monitor configuration 

Updating the WebSphere Business Monitor configuration is a required task, 
regardless of whether Alphablox is installed. It registers models with the Data 
Services Scheduler and updates the cube configuration on the WebSphere 
Business Monitor V7.0 profile. You can complete this task by running the 
monConfigurationUpgrade script. 
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Note: During the update of the WebSphere Business Monitor configuration, all 
the WebSphere Business Monitor related servers should be started 
(deployment manager, all the custom nodes, five clusters: WPS. Messaging, 
WPS.Support, WBM. Support, WBM.AppTarget, and BPM. Dashboard in our 
environment). 

Start the deployment manager first. 


To update the WebSphere Business Monitor configuration, perform the following 
steps: 

1 . Stop all the node agents and target deployment manager. Restart the target 
deployment manager. 

2. Start each target custom node by running the startNode . bat command under 
the target _custom _profile_root /bin directory on each machine. 

3. Log in to the administrative console as an administrative user ID. 

4. Start the six clusters in sequence: 

a. WPS.Messaging 

b. WPS.Support 

c. WPS.AppTarget 

d. WBM. Support 

e. WBM.AppTarget 

f. BPM.WebDashboard 

Note: 

► The clusters should be started one at a time in the sequence shown 
above. 

► Check the log files for possible errors after the servers are started. 

5. Log in to one of the machines where the WebSphere Business Monitor 
custom node is installed with the administrator user ID. 

6. Open the 

target_custom _profi lejroot \scri pts . wbm\mi grati on\conf i gurati on\monCo 
nfigurationllpgrade.bat file by using a text editor: 

C : \wdpe7\scri pts .wbm\mi grati on\confi gurati on\monConf i gurati onllpgrade 
.bat 
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Update the values shown in Example 6-84. The updated values are 
highlighted in bold. 


Note: If you are using a network deployment environment, you must 
configure the WSADMINJHOST, WSADMIN_PORT and 
WSADMIN_USER settings to refer to the deployment manager of the cell, 
not an individual node. The underlying code for this operation is configured 
to the scope of the deployment manager. Therefore, if you configure the 
script to refer to a node other than the deployment manager, you will 
receive an error. 


Example 6-84 monConfigurationUpdade.bat file 

set WSADMIN_H0ST=saw007-sysl. itso.ral .ibm.com 

set WSADM I N_P0RT=8879 

set WSADMIN_CONN_TYPE=SOAP 

set WSADMIN_USER=admin 

set WSADM I N_PASSWORD=admi n 

set 

WSADM I N_C LASS PATH=%WAS_HOM E%\ p 1 ugi ns\com. i bm.wbimoni tor . 1 ifecycle.sp 
i .jar 

set ABX_H0ST=saw016-sys3. itso.ral .ibm.com 
set ABX_P0RT=9811 
set ABX_USER=admin 
set ABX_PASSWORD=admi n 


- WSADMIN_HOST refers to the host name of target deployment manager 
machine. 

- WSADMIN_PORT refers to the SOAP_CONNECTOR_ADDRESS port of 
the deployment manager. 

- WSADMIN_CONN_TYPE specifies the connection type. Here we use 
SOAP. 

- WSADMINJJSER and WSADMIN_PASSWORD are the profile 
administrative user ID and password. 

- ABXJHOST is the host name of the machine where Alphablox is installed. 

- ABX_PORT is the SOAP_CONNECTOR_ADDRESS of the 
BPM.WebDashboard.WBMNodeOI .0 server. 

- ABX_USER and ABX_PASSWORD are the profile administrative user ID 
and password. 
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7. Execute monConfigurationllpgrade.bat to update the monitor configuration. 
The command output is shown in Example 6-85. The input is highlighted in 

bold. 

Example 6-85 Command output of monConfigurationUpgrade.bat 

C:\wdpe7\scripts.wbm\migration\configuration>monConfigurationUpgrade 

.bat 


Upgrade the Monitor configurations from 6.x to 7.0 


Please check the required wsadmin parameters defined in 
monConfigurationUpgrade.bat, and they are used to connect to the 
Monitor server. 

<WSADMIN_H0ST> = saw007-sysl.itso.ral.ibm.com 
<WSADMIN_PORT> = 8879 
<WSADMIN_CONN_TYPE> = SOAP 
<WSADMIN_USER> = admin 
<WSADM I N_PASSW0RD> = admin 


Please also check the optional Alphablox server configuration, 
and the cubes on the default or specified Alphablox server will be 
upgraded. 

<ABX_H0ST> = saw016-sys3.itso.ral.ibm.com 

<ABX_P0RT> = 9811 

<ABX_USER> = admin 

<ABX_PASSWORD> = admi n 


Usage 1: upgrade the cubes in the default Alphablox server which 
was specified in the Monitor database 
<ABX_H0ST> = . 

<ABX_P0RT> = . 

<ABX_USER> = . 

<ABX_PASSWORD> = . 

Usage 2: upgrade the cubes in the specified Alphablox server with 
security disabled 

<ABX_H0ST> = hostname or IP (e.g. localhost) 

<ABX_P0RT> = BOOTSTRAP_ADDRESS (e.g. 2809) 

<ABX_USER> = . 

<ABX_PASSWORD> = . 

Usage 3: upgrade the cubes in the specified Alphablox server with 
security enabled 

<ABX_H0ST> = hostname or IP (e.g. localhost) 

<ABX_P0RT> = BOOTSTRAP_ADDRESS (e.g. 2809) 

<ABX_USER> = user 
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<ABX_PASSWORD> 


= password 


Continue? [Input Y to continue or input N if you want to modify the 
listed parameters] :Y 

Please input the version of the old Monitor[61 or 62]:61 

Start to upgrade the Monitor configurations, and after it's 
completed, you could check the log file: 

C : \wdpe7\l ogs\wbm\mi grati on\moni torconf i gurati onupgradel og . txt . 


8. Check the monitor_configuration_upgrade_log.txt log file (the location is 
shown in the command output in bold in Example 6-85 on page 317) for the 
message shown in Example 6-86 to ensure that the updating is successful. 

Example 6-86 Success message in the log 

Info - finish to update all Alphablox cubes successfully. 


Errors?: If you find error WASX7017E in the log, refer to 6.7.3, “Alphablox 
cubes cannot be created” on page 335. 


6.6 Verify the migration target environment 

After migration, restart the entire target environment. 

Stop the servers, one at a time, in the following sequence: 

1. BPM.WebDashboard cluster 

2. WBM.AppTarget cluster 

3. WBM. Support cluster 

4. WPS.AppTarget cluster 

5. WPS.Support cluster 

6. WPS.Messaging cluster 

7. All the node agents 

8. Deployment manager 
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Start the servers, one at a time, in the following sequence: 

1 . Deployment manager 

2. All the node agents 

3. WPS.Messaging cluster 

4. WPS.Support cluster 

5. WPS.Target cluster 

6. WBM. Support cluster 

7. WBM. AppTarget cluster 

8. BPM.WebDashboard cluster 


6.6.1 Verify the log files 

After starting the target environment, check the SystemOut . 1 og files for each 
server first. On each machine, navigate to the 

target _profi lejroot / 1 ogs / Server _Name directory and check the SystemOut . 1 og 
file. There should be no fatal errors and you should see the “open for e-business” 
message (Example 6-87). 

Example 6-87 Server successful start message 

Server RMSgold. AppTarget. aix224Node02.0 open for e-business 


Errors?: If you see the UTLS0002E message for the ABXJJBS shared 
library, refer to 6.7.4, “Shared libraries for Alphablox” on page 339. 


6.6.2 Check the messaging engine status 

Check the messaging engine status to ensure all the messaging engines are 

running by performing the following steps: 

1 . Log in to the administrative console and navigate to Service integration ->• 
Buses. Click one of the bus names (for example, BPC.WDPECell.Bus). 

2. Select Topology ->• Messaging engines. 

3. The messaging engine should be in the started status. 

4. Follow steps 1 - 3 to check the messaging engine status for all the other 
buses. If any of the messaging engines are not in the started status, check the 
SystemOut . 1 og file of the corresponding application server for the root cause 
of the problem. 
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6.6.3 Verify the applications 


Log in to the administrative console and make sure that all the applications are 
started by performing the following steps: 

1 . Log in to the administrative console and navigate to Applications -» 
Application Types -» WebSphere enterprise applications. 

2. All the applications should be in the started status, as shown in Figure 6-59. 


You can administer the following resources: 

□ 

AlDhabloxPlatform 


□ 

AppScheduler 


□ 

ADDlicationStudio 


□ 

BPCECollector WPS.Support 

♦ 

□ 

BPCExDlorer WPS.SuDDort 

♦ 

□ 

BPCObserver WPS.Support 


□ 

BPEContainer WPS.AoDTaraet 


□ 

BSpaceEAR BPM.WebDashboard 

♦ 

□ 

BSDaceWebformsEnabler BPM.WebDashboard 

♦ 

□ 

BusinessRulesManaaer WPS.Support 

♦ 

□ 

BusinessRules BPM.WebDashboard 


□ 

BusinessSpaceHelpEAR BPM.WebDashboard 

♦ 

□ 

EomsMMADDlication 


□ 

EomsManaae0616App 

♦ 

□ 

GlobalHTMMADDlication 

♦ 

□ 

HTM PredefinedT askMso V612 WPS.ADoTaraet 


□ 

HTM PredefinedTaskMsa V700 WPS.ADDTaraet 


□ 

HTM PredefinedTasks V612 WPS.ADDTaraet 


□ 

HTM PredefinedTasks V700 WPS.ADDTaraet 

♦ 

□ 

HumanTaskManagementWidgets BPM.WebDashboard 


□ 

IBM WBM ACTIONSERVICES 

♦ 

□ 

IBM WBM DATA SERVICES 


Page: 1 of 2 [0 Total 42 


Figure 6-59 Application status 
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Note: If any application is not in the started status, check the 
SystemOut.log file of the application server and the previous migration log 
file. 


3. Navigate to Applications -» Monitor Models. 

4. Make sure the Deployment status is the same as in the pre-migration 
environment, as shown in Figure 6-60 (OK in our environment). 


El Preferences 

Start | Stop | Install | 


Select Model 0 Version 

Deployment 0 

□ 

EomsMM 

2008-06- 

16T21:07:19 

OK 

□ 

GlobalHTMM 

2007-06- 

18T09:54:38 

OK 

□ 

NewLoanProcessMM 

2010-04- 

OK 



05T09:41:32 


□ 

NewLoanProcessMM 

2010-04- 

07T09:41:32 

OK 

□ 

NewLoanProcessMM 

2010-04- 

OK 


08T09:41:32 

□ 

NewLoanProcessMM 

2010-04- 

OK 


08T16:41:32 

Total 6 


Figure 6-60 Monitor model deployment status 


6.6.4 Verify the WebSphere Process Server failed events 

If there are WebSphere Process Server failed events left before migration, check 
those failed events from the administrative console to make sure that no failed 
event is lost during migration. 

Perform the following steps: 

1 . Log in to the administrative console and navigate to Integration 
Applications ->■ Failed Event Manager. 
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2. Check the recovery sub-system status and application server version 
information at the right-top corner of your window, as shown in Figure 6-61 . 


@ About your failed event manager 

♦ The Recovery sub-system is enabled. 
T otal failed events 


33 

IBM WebSphere Application Server - ND, 
Build Number: wps0946.04 
Build Date: 11/18/09 

7.0. 0.7 

Si 

1 

Licensed Material - Property of IBM 
5724d08. 5724-163. 5724-H88. 5724-H89, 
5733-W70 (C) Copyright IBM Corp. 1996, 

5655-N02, 

2008 

9 


Figure 6-61 Recovery subsystem status 
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3. Click Get all failed events, and you should see all the legacy failed events, as 
shown in Figure 6-62. In the failed event list, we can see that the additional 
failed events from the BPC modules are shown. Displaying the failed events 
from business process choreographer applications is a new feature in 
WebSphere Process Server V7.0. 


Failed Event Manager > Search results 

The failed events result set shows the failed events found from tf 
Use the buttons below to manage the failed events in the current 
El Preferences 

Refresh Get all | New search... | Resubmit | Resubn 


Select Event ID 0 

Event type 0 

Module 0 

□ 

1B747FE9999D0BD3.. 

SCA 

rrso_impl_vl 


□ 

1B747FE9999D0BD3 . . 

SCA 

rrsojmpLvi 


□ 

1B747FE9999D0BD3 . . 

SCA 

rTSO_impl_vl 


□ 

1B747FE9999D0BD3 . . 

SCA 

ITSOJmpLvl 


□ 

1B747FE9999D0BD3 . . 

SCA 

ITSOJmpLvl 


□ 

1B747FE9999D0BD3 . . 

SCA 

ITSOJmpLvl 


□ 

1B747FE9999D0BD3. . 

SCA 

ITSOJmpLvl 


□ 

1B747FE9999D0BD3. . 

SCA 

ITSOJmpLvl 


□ 

PI : 90030 128. 419. . 

BPC 

rrso_v 2 


□ 

PI: 90030 128. 432.. 

BPC 

rrso_v 2 


Page: 1 of 4 Tl Total 33 


Figure 6-62 Failed event manager 
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4. We can successfully resubmit one of the legacy failed events, as shown in 
Figure 6-63. 


E Messages 

0 Failed event [_PI:90030128.4192517.5154d5f6.e8c400d0] was resubmitted successfully. 


Figure 6-63 Resubmit failed event successfully 


6.6.5 Verify WebSphere Business Monitor failed events 

If you have any WebSphere Business Monitor failed events before migration, you 

can check the failed events on the administrative console to make sure they are 

migrated by performing the following steps: 

1 . Log in to the administrative console and navigate to Troubleshooting 
Monitor Models ->■ Failed Event Sequences. 

2. Check the failed instances for each monitor model. The list should be the 
same as in the pre-migration environment. 

3. Click the failed instances number and you can see the failed event number for 
each of the instances. 

6.6.6 Verify the BPC Client 

If you have long running BPEL instances in place before migration, you can log in 

to BPC Explorer to check the legacy instances by performing the following steps: 

1 . Log in to the BPC Explorer with the admin user ID at 
http://saw016-sysl.itso.ral . i bm.com: 9081/bpc. 

2. Navigate to Process Instances -> Administrated By Me. 
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3. We can see all the legacy BPEL instances, as shown in Figure 6-64. 


Process Instances for Process Templates 

Use this page to work with process instances that belong to spe 

| Terminate | Delete | Suspend | Resume | Restart | Compens. 

r Process Instance Name 0 

r _PI:90030128.823ab49.5154d5f6.ecde0005 
r _PI:90030128.7ca44df.5154d5f6.7c20084 
T _PI:90030128.7d72968.5154d5f6.7c200cO 
r _PI:90030128.7da4acd.5154d5f6.7c200fc 
T _PI:90030128.808ff48.5154d5f6. 7290000 
T _PI:90030128.813abd3.5154d5f6. 7290045 
r _PI:90030128.835ad83.5154d5f6.ecde0033 
r _PI:90030128.8391b23.5154d5f6.ecde006d 
T _PI:90030128.8397bc2.5154d5f6.ecde009b 
r _Pl:90030128.839ec5e.5154d5f6.ecde00d5 
T _PI:90030128.83a523c.5154d5f6.ecde0104 
r _PI:90030128.83b010a.5154d5f6.ecde013e 
r _PI:90030128.83b6f93.5154d5f6.ecde016c 
r _PI:90030128.84ccf06.5154d5f6.ecde01c8 
r _PI:90030128.84d25bl.5154d5f6.ecde01eb 
T _PI:90030128.84d4a8f.5154d5f6.ecde0215 
r _PI:90030128.84dbec5.5154d5f6.ecde0238 
r _PI:90030128.84de642.5154d5f6.ecde0261 
r _PI:90030128.84e2dab.5154d5f6.ecde028a 
r _PI:90030128.84eacce.5154d5f6.ecde02b4 
r _PI:90030128.84f61b7.5154d5f6.ecde02d7 
r _PI:90030128.84f86a4.5154d5f6.ecde0300 
T _PI:90030128.8500fe8.5154d5f6.ecde0329 
Items found: 23 Items selected: 0 
Figure 6-64 Legacy BPEL instances 
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4. If you migrated the BPC Observer, click Reports to see the reports in the 
BPC explorer (Figure 6-65). 



Figure 6-65 Report in BPC Explorer 


6.6.7 Verify the Business Rules Manager 

Log in to the Business Rules Manager to check the business rules by performing 
the following steps: 

1 . Log in to the Business Rules Manager with the user ID admin at 
http://saw016-sysl.itso.ral . ibm.com: 9081/br. 

2. Navigate to Business Rule Groups. 


326 Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 


3. Expand one of the business rules, for example, RatingService -» 
performRiskRating ->• performRiskRating, and check the details 
(Figure 6-66). 


Address 


|© https://saw016-sysl.itso.ral.ibm.com:9444/br/pages/index.jsp 


Welcome admin | Logout | Search | Help 

Publish and Revert performRiskRating - Decision Table 

Back | Edit | Copy | 


Business Rule Groups 

3 1 RatingService 

S §1 performRiskRating General Information 

b performRiskRating 


Last Published 

Apr 16, 2010 14:00 (Local Time) 

Description 



Decision Table 


Input. VINLookupStatus.toUpperCase() "NOT CLEAN" 

InputCreditScore - 4 

Output.RiskRatingScore-t 

>= 720 

"Medium" 

>=580 and <720 

"High" 

<580 

"High” 


Figure 6-66 Business Rules Manager 


6.6.8 Verify the Alphablox administrative console 

Log in to the Alphablox administrative console at 

http://saw016-sys3.itso.ral .ibm.com:9082/AlphabloxAdmin to see if the 
cubes for each model version are running, as shown in Figure 6-67. 



Cube 

EOMSMM_ 

EOMSMM_CIRATTEMPER_MAINBPEL_CUBE_2 00 8 0616210719 

Name 

GLOBALHTMM_HtJMANTASK_CUBE 
GLOBALHTMM_HUMANTAS K_CUBE_2 0070618095438 
NEWLOANPROCESSMM_NEW_LOAN_PROCESS_CUBE 
NEWLOANPROCESSMM_NEW_LOAN_PROCESS_CUBE_20100405094132 

Status 

Last 

Started 

Running 

04:21:2010 

NEWLOANPROCES SMM_NEW_LOAN_PROCES S_CUBE_2 0100407094132 

Last 


NEWLOANPROCESSMM_NEW_LOAN_PROCESS_CUBE_2 01004 0 8094132 
NEWLOANPROCESSMM_NEW_LOAN_PROCESS_CUBE_2 01004 08 1 64132 

Stopped 



Figure 6-67 Checking the cube status in the Alphablox administrative console 
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6.6.9 Verify Business Space 


You can log in to Business Space with different user IDs to check that all the 
legacy spaces, pages, and widgets are displayed by performing the following 
steps: 

1 . We log in as the ITSORequester user to see the legacy space shown in 
Figure 6-68. 



Figure 6-68 Legacy space for ITSORequester 
2. We log in as the ITSOMonitor user to see the space shown in Figure 6-69. 


kpis - _ n 



Os 15m 0.00% 100.00% 0 40 


Figure 6-69 Legacy space for ITSOMonitor user 


3. You can also create a new Business Space using a template. 
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Errors?: If you find that some or all of the WebSphere Business Monitor 
widgets do not work properly, refer to 6.7.2, “REST Services port error” on 
page 332 for a possible solution. 


6.6.10 Verify long running BPEL instances 

Next, verify that the migrated long running BPEL instances are intact by 
performing the following steps: 

1 . Log in to Business Space as the ITSOApprover_member01 user. 

2. You can successfully claim and complete one of the available tasks to finish 
one legacy BPEL instance for the sample application. This indicates that the 
long running BPEL instances are migrated successfully and WebSphere 
Process Server is working properly after migration. 

3. Log in to Business Space as the ITSOMonitor user. You will see that the 
newly executed instance is complete. 

4. Launch a new instance as ITSORequester using Business Process 
Choreographer Explorer. In the instance widget, you can see that there is one 
more instance. 

This shows that WebSphere Dynamic Process Edition is working properly for 
long running instances after migration. You can also check the other widgets on 
the Business Space for a thorough testing. 


6.7 Troubleshooting 

In this section, we describe the issues we encountered during our migration 
procedure. 

6.7.1 Update the outbound CEI event service 

After migration, we found that the outbound CEI event service was not in the 
correct state. 
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Symptom 

After deploying the WebSphere Business Monitor scheduled services, we used 
the administrative console to navigate to Servers -» WebSphere Business 
Monitor configuration. We saw a red cross for Outbound CEI event service, 
as shown in Figure 6-70. 



Component 

Status 

e 

Outbound CEI event service 


Q 

Messaging engine 

Deployed on WPS. Messaging 

□ 

Action services 

Deployed on WBM. Support 

□ 

Monitor scheduled services 

Deployed on WBM. Support 


Figure 6-70 Outbound CEI event service configuration has a red X 


Solution 

If you encounter this problem, perform the following steps to solve the problem: 

1 . Log in to the administrative console and navigate to Service integration 
Common Event Infrastructure -» Event emitter factories. 

2. Click Monitor Emitter Factory, as shown in Figure 6-71 (Monitor Emitter 
Factory in our environment). 


0 Environment 




El Integration Applications 


All scopes 


0 System administration 

0 Preferences 


0 Users and Groups 

New | 

Delete | 


0 Monitoring and Tuning 

e e 

mm 


0 Troubleshooting 


0 Service integration 

Select 

Name 0 

Scope 0 

■ Buses 

You c 

an administer the following resources: 

■ WSRR definitions 

□ 

Default Common 

Cluster=WPS. Support 

■ SCM connectivity providers 
0 Common Event Infrastructure 
■ Event service 


Infrastructure 

emitter 

■ Event emitter factories 
0 Web services 
0 WS-Notification 

□ 

Monitor Emitter 

Cell=WDPECell 

Total 2 


Figure 6-71 Event emitter factories 


3. In the Additional Properties section, click the Event service transmission 
link. 
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4. Replace the JNDI name with: 

cel 1 /cl usters/cZus£er_r?ame/com/i bm/events/conf i gurati on/bus-transmi s 
sion/Default 

The cluster_name is the cluster name where the common event infrastructure 
service is deployed. In our example (Figure 6-72), we use the following value: 

cel 1 /cl usters/WPS.Support/com/ibm/events/configuration/bus-transmiss 
ion/Default 

The default is com/i bm/events/conf i gurati on/bus-transmi ssi on/Defaul t. 


Event emitter factories > Monitor Emitter Factory > Default CEI event bus transmission 

These settings define the location of an event service. The Event Service Transmission settings 
to the event service using EJB calls. 

Configuration 

General Properties 

* Scope 

|cells:WDPECell | 

* Name 

|Default CEI event bus transmission 

* JNDI name 

|cell/dusters/WPS.Support/com/ibm/events/configuration/bus-transmission/Default 

Description 

|A transmission profile with points to the event server profile shipped with the Common I 

Category | 

■ Fvenf service 1NDI name 

©Select an event service within this cell 

cell/dusters/WPS.Support v | 

O JNU1 name of an event service in a different cel l 

| Apply | OK| Reset | [ Cancel | 

Figure 6-72 Default CEI event bus transmission 

5. Navigate to Service integration Common Event Infrastructure Event 
emitter factories. 

6. Under Component, select Outbound CEI event service. 

7. Click Monitor Emitter Factory. 
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8. Select the JNDI name you just entered as the JNDI name for event service 
transmission. In our example, we select: 

cel 1 /cl usters/WPS.Support/com/ibm/events/configuration/bus-transmiss 
ion/Default 

9. Click OK. 

6.7.2 REST Services port error 

After migration, we found that not all of the WebSphere Business Monitor widgets 
work properly. 

Symptom 

After we log in to the Business Space, we cannot view any data in the Monitor 
instance widget. Other widgets display Widget Needs Configuration on the 
legacy space we configured before migration (Figure 6-73). 

; Address jffi http://saw016-sys3.itso.ral.ibm.com:9082/mum/enabler#pid=id_1271360808908& 


Home Go to Spaces Manage Spaces 1 Actions 

B Business Monitoring Workspace 



Figure 6-73 No data is shown in Monitor widgets 
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When we add a new widget in the page and try to configure it, the warning shown 
in Figure 6-74 opens. 



Figure 6-74 Warning window when configuring a new widget 

When we check the logs for the BPM.WebDashboard cluster 
(C:\wdpe7\profi les\WBMCust01\logs\BPM.WebDashboard.WBMNode01.0\System0u 
t.log), we find the errors shown in Example 6-88. 

Example 6-88 Rest Service API error message 

[4/21/10 16:28:11:078 EDT] 00000056 webcontainer E 
com.ibm.ws.webcontainer.WebContainer handl eRequest SRVE0255E: A 
WebGroup/Virtual Host to handle 

/rest/bpm/monitor/alerts/dashboardalerts has not been defined. 

[4/21/10 16:30:50:265 EDT] 00000057 webcontainer E 

com. ibm.ws. webcontainer. WebContainer handl eRequest SRVE0255E: A 

WebGroup/Virtual Host to handle 

/rest/bpm/moni tor/model s/NewLoanProcessMM/cubes/NEWL0ANPR0CESSMM_NEW_L0 
AN_PR0CESS_CUBE/saw016-sys3_9445 has not been defined. 
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Root cause 

This error occurs because the REST services port is set incorrectly after 
migration (Figure 6-75). 


WebSphere application server clusters > BPM.WebPashboard > REST services 
Configure services for Representational State Transfer (REST) system interfaces. For 
virtual host and the port that a client uses to communicate with your server or cluste 

Configuration 

REST services 

Protocol: 

| https:// \&tt\ 

* Host name or virtual host in a load- balanced environment: 

|saw016-sys3 

♦ Port: 

|9445 


Context root: 
l/rest 


Enabled 

Type 

Description 

0 

Time Tables 


|WBI Business Calendar REST API 


0 

Business 

Rules 

|WBI Business Rule REST API 


Figure 6-75 REST Services port 

REST_Services_Gateway is deployed on the WBM. Support cluster and the 
WC_defaulthost_secure port for WBM.Support.WBMNodeOI .0 is 9443. We need 
to modify the REST services port to 9443. 

Solution 

Perform the following steps to correct the REST services port: 

1 . Log in to the administrative console and navigate to Servers — > Clusters 
WebSphere application server clusters. 

2. Click BPM.WebDashboard. 

3. Select Business Integration REST services. 
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4. Modify the port to 9443 (Figure 6-76). 


n server clusters > BPM.WebDashboard > REST services 
Configure services for Representational State Transfer (REST) system interfaces. For 
virtual host and the port that a client uses to communicate with your server or cluste 


Configuration [ 


REST services 

Protocol: 

I https:// H 

♦ Host name or virtual host in a load-balanced environment: 
|saw016-sys3 


Port: 

|9443 


Context root: 


l/rest 


Figure 6-76 Correct port for REST services 


5. Click OK. 

6. Restart the BPM.WebDashboard cluster. 


6.7.3 Alphablox cubes cannot be created 

Updating the monitor configuration fails because the Alphablox cubes cannot be 
created. 

Symptom 

After updating the monitor configuration, we found the error shown in 
Example 6-89 in the monitor_configuration_upgrade_log.txt log file. 

Example 6-89 Error message in monitor_configuration_upgrade_log. txt 

Info - [EomsMM/20080616210719] recreate the Alphablox cubes. 

WASX7017E: Exception received while running file 
"monConfigurationllpgrade. jy"; exception information: 
javax. management .MBeanExcepti on 

java . 1 ang .Null Poi nterExcepti on : java . 1 ang .Null Poi nterExcepti on 
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When we check the log for the BPM.WebDashboard cluster member 

(C : \wdpe7\prof i 1 es\WBMCust01\l ogs\BPM . WebDashboard .WBMNodeOl . 0\System0u 

t.log), we found the errors shown in Example 6-90. 

Example 6-90 AlphabloxConf exception when creating cubes 

[4/21/10 17:05:51:156 EDT] 0000005f AlphabloxConf E 
com. ibm.wbimoni tor .al phabl ox.mbeans . A1 phabl oxConf igMBeanlmpl 
createCube( String, Map ) CWMLC6211E: Al phabl oxConf ig MBean failed. 
Cause: [DB2 SQL Error: SQLC0DE=-805, SQLSTATE=51002, 
SQLERRMC=NULLID.SYSLN203 0X5359534C564C3031, DRI VER=3 . 51 . 90 ( DB2 SQL 
Error: SQLC0DE=-805, SQLSTATE=51002, SQLERRMC=NULLID.SYSLN203 
0X5359534C564C3031 , DRI VER=3. 51 . 90 )] . 


On the administrative console, the “Alphablox cubes created” option shows a red 
cross, as shown in Figure 6-77. 


Monitor Models > EomsMM r2008-06-16T21:07:19) 

Use this page to tune and configure the error handling and KPI properties of this model version. 
General 

General Properties 

Version ProDerties 

Model 

|EomsMM 

■ Manaae schema 

Version 

Manaqe Alphablox Cubes 

|2008-06-16T21:07:19 

■ Enable Data Movement Service 

Application 

■ Chanae CEI distribution mode 

|EomsMMApplication 

■ Chanae runtime confiauration 

CEI distribution mode 


lActive (monitor model queue- 

■ View model 

Ibased) 

■ Purae model version 

Active MC instances 

Manaqe Monitor Data 

l» 1 


■ Export Instance Data 

Deployment 

■ Purae and Archive Instance Data 

D Dashboards enabled 

Q Schema created 

©Alphablox cubes created (optional) 

OData Movement Service enabled (optional) 



Figure 6-77 Alphablox cubes created status 
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Root cause 

This error occurs because Alphablox tries to access the SYSLN203 package, 
which was not created in the database. As a result, the cubes cannot be created. 

Solution 

To fix the problem, perform the following steps: 

1 . On the DB2 server machine, open a DB2 command-line window. 

2. Execute the command shown in Example 6-91 to rebind db2cli.lst to CLIPKG 
20. 

Example 6-9 1 Rebind db2cli. 1st command 

C:\backup\afterBSpace>db2 connect to MONITOR user db2admin using 
password 

Database Connection Information 

Database server = DB2/NT 9.5.0 

SQL authorization ID = DB2ADMIN 

Local database alias = MONITOR 

C:\backup\afterBSpace>db2 "bind c:\IBM\DB295\bnd\Qdb2cli.lst 
blocking all sqlerror continue grant public CLIPKG 20" 

LINE MESSAGES FOR db2cli. 1st 


SQL0061W The binder is in progress. 

SQL0091N Binding was ended with "0" errors and "0" 
warnings. 

C:\backup\afterBSpace>db2 "select pkgname from syscat. packages where 
pkgname= 1 SYSLN203 1 " 

PKGNAME 


SYSLN203 

1 record(s) selected. 

C:\backup\afterBSpace>db2 connect reset 
DB20000I The SQL command completed successfully. 

3. Rerun the monConfigurationllpgrade.bat command to update the Alphablox 
cubes for other models. 
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4. We need to create the Alphablox cubes manually for the EomsMM model. 
The monConfigurationllpgrade.bat command will not create the cubes for 
this model during re-execution. 

5. On the administrative console, navigate to Applications -» Monitor Models. 

6. Click Version of EomsMM (2008-06-1 6T21 :07:19 in our environment). 

7. Click Manage Alphablox Cubes under Version Properties. 

8. The window shown in Figure 6-78 opens. Click Create. 


Monitor Models > EomsMM { 2008-06-16T21:07:19) > Manage Alphablox Cubes 
Use this page to supply the Alphablox host connection setting and then create the cubes. 
After the cubes have been created, you can remove or export them. 

To export the cubes XML and properties files into a zip file, click Export Cubes. 

Alphablox host connection settings 
Location 

® Local O Remote 

IsawO 16-sys3.itso.rai] 

|9811 ~ 

Security 

; 

Export Cubes | 

Create | Remove | Cancel | 

Figure 6-78 Create Alphablox cubes manually 
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The Alphablox cubes are successfully created (Figure 6-79). 


General Properties 

Model 

|EomsMM | 

Version 

|2008-06-16T21:07:19 | 

Application 

lEomsMMApplication ~| 

CEI distribution mode 

I Active (monitor model queue- 
|based) ' | 

Active MC instances 

N I 

Deployment 
D Dashboards enabled 
D Schema created 
D Alphablox cubes created (optional) 

OData Movement Service enabled (optional) 

Figure 6-79 The Alphablox cubes have been successfully created 


6.7.4 Shared libraries for Alphablox 

After migration, there can be error messages indicating that shared libraries are 
not found for Alphablox in the WebSphere Process Server logs. 

Symptom 

After starting the target environment after migration, there are several exceptions 
for the ABXJJBS libraries in SystemOut.log for the WPS.Messaging, 
WPS.Support, and WPS.AppTarget members (Example 6-92). 

Example 6-92 Shared library not found logs 

[4/20/10 14:32:19:718 EDT] 00000000 Modul eMani fes E UTLS0002E: The 
shared library ABX_LIBS contains a classpath entry which does not 
resolve to a valid jar file, the library jar file is expected to be 
found at C:\wdpe7\Alphablox\lib\aasreputil.jar. 
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Root cause 

This error occurs because the ABX_LIBS shared library is configured at the cell 
scope, but Alphablox is not installed on the WebSphere Process Server systems. 
Because our WebSphere Process Server does not use Alphablox, the exception 
can be safely ignored. 

Solution 

Simply ignore the exceptions about ABX_LIBS in WebSphere Process Server 
logs if the node is a WebSphere Process Server custom node. 
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7 


Migrating WebSphere 
Process Server V6.1.2 to 
V7.0 on a z/OS system 


This chapter provides a detailed example of a walkthrough with instructions for 
migrating a WebSphere Process Server V6.1 .2 runtime environment on a z/OS 
system to Version 7.0 with full downtime. This topology is configured with a single 
cluster topology, which includes two servers on two separate nodes on the same 
z/OS system. 

This chapter contains the following sections: 

► “Source environment overview” on page 342. This section describes the 
source environment that is to be migrated on z/OS. The source environment 
topology, databases, nodes, cluster and servers, sample applications 
deployed are introduced. 

► “Installing WebSphere Process Server V7.0 on z/OS” on page 351 . This 
section provides full instructions to install WebSphere Process Server V7.0 
on a z/OS system. 

► “Migrating the runtime environment” on page 352. This section provides full 
instructions to migrate the existing topology from Version 6.1 .2 to Version 7.0 
with full downtime on z/OS. 
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► “Post-migration verification” on page 438. This section describes the 
instructions to perform the post-migration verifications. You will examine the 
target environment and verify if the migration process has successfully 
created the corresponding objects in the target environment. 

► “Troubleshooting” on page 445. This section describes issues that were 
discovered and fixed during the migration on z/OS. 


7.1 Source environment overview 

This section briefly describes the Version 6.1 .2 source environment that will be 
migrated to Version 7.0. 

7.1 .1 Source environment topology 

The source topology is a single cluster topology that includes two servers on two 
separate nodes on the same z/OS system, as shown in Figure 7-1 . 



Figure 7-1 Source environment topology 
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The single cluster pattern is the default topology of WebSphere Process Server 
for z/OS. All components are run on a single cluster: 

► Service Component Architecture (SCA) application bus members 

► SCA system bus members 

► Business Process Choreographer (BPC) bus members 

► Common Event Interface (CEI) bus members 

► Business Process Choreographer components, such as the explorer 

► Business Process Choreographer container 

► Business Rules Manager 

► CEI server 

► Application deployment target 


7.1.2 Sample application 

We used the sample application to generate long-running BPEL instances, 
human tasks, and failed events. We later verify, in the target environment, 
whether they are intact during post-migration. 

The sample application was deployed and started. For migration, the following 
situation exists: 

► Several process instances were started. 

► Several process instances and human tasks are found in BPC explorer. 

► Several fail events were generated. 

For more information about the sample application, refer to 5.6.1 , “Sample 
application description” on page 178 and 5.6.2, “Features included in the sample 
application” on page 179. 

7.1 .3 Source environment checking 

In this section, we check the source environment to see if it is set correctly. 
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Installed software versions 

Log into the administrative console and check the software versions of the 
source environment (Figure 7-2). 


lists the product suites that can be administered through this installation. Select a product suite 
information. 



i w^SphereProcessS^^r I 6. 1.2. 3 | 


Figure 7-2 Administrative console of the source environment 

Cell topology 

Log into the administrative console and observe the source environment 
(Figure 7-3). 


Local Topology 


Cell 

1=1 IldQl 
BGfr Nodes 

B tA Cluster members 
'ft IldQll 

□ (J) llnodeb (Business Process Choreographer 6.1.2.3, HD 6.1.0.28, WPS 6.1.2.3) 
B ^ Cluster members 

ft lldQ12 


Figure 7-3 Cell topology 
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Enterprise applications 

Before migration, we deploy the sample applications to the source environment. 
You can check the status of the enterprise applications including the system and 
sample applications in the administrative console (Figure 7-4). 



Figure 7-4 Applications deployed in the source environment 
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Process instances 

For verification purposes, we also do some data preparation based on the 
sample application. Before migration, some long running BPEL instances and 
human tasks are generated (Figure 7-5). These instances will be left there until 
post-migration. 


Process Instances for Process Templates 

Use this page to work with process instances that belong to specific process templates. 0 

] Compensate | Terminate | Delete Suspend | Resume | Restart 

| Activities | Related 

Process Instance Name 0 

Process Template Name 

0 State 0 

Start 

r _PI: 90030127. dde62289.dffbf3f6. 30760066 

New Loar 

i Process VI 

Finished 

4/8/1 

□ _PI: 90030127. dde7218a.dffbf3f6.307600a2 

New Loar 

i Process VI 

Finished 

4/8/1 

D _PI: 90030127. dde770ba.dffbf3f6.307600dd 

New Loar 

i Process VI 

Finished 

4/8/1 

O _PI: 90030127. dde7bb36.dffbf3f6. 30760118 

New Loar 

i Process VI 

Finished 

4/8/1 

D _PI : 90030127 ,dde8090a ,dffbf3f6 .30760153 

New Loar 

i Process VI 

Running 

4/8/1 

n _PI : 90030127. dde8510d.dffbf3f6.3076018e 

New Loar 

i Process VI 

Running 

4/8/1 

□ _PI: 90030127. dde89415.dffbf3f6.307601c9 

New Loar 

i Process VI 

Running 

4/8/1 

□ _PI: 90030127. dde8e08d.dffbf3f6. 30760204 

New Loar 

i Process VI 

Running 

4/8/1 

□ _PI: 90030127. dde92381.dffbf3f6.3076023f 

New Loar 

i Process VI 

Running 

4/8/1 

□ _PI: 90030127. ddf0fca7.dffbf3f6 ,3076027a 

New Loar 

i Process VI 

Running 

4/8/1 

□ PI; 90030127 ,de0fl376 ,dffbf3f6 .93930022 
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i Process VI 

Failed 

4/8/1 

O _PI: 90030127. del0033e.dffbf3f6. 93930041 

New Loar 

i Process VI 

Failed 

4/8/1 

□ _PI: 90030127. del05345.dffbf3f6. 93930060 

New Loar 

i Process VI 

Failed 

4/8/1 

□ _PI: 90030127. del0a043.dffbf3f6.9393007f 
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i Process VI 
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4/8/1 

□ _PI: 90030127. del0eda7.dffbf3f6.9393009e 

New Loar 

i Process VI 
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4/8/1 

□ _PI: 90030127. deecb5a3.dffbf3f6.96ed0000 

New Loar 

i Process VI 
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4/8/1 

□ _PI: 90030127. def53c70.dffbf3f6.96ed0021 

New Loar 

i Process VI 

Terminated 

4/8/1 

□ _PI: 90030127. def5f30b.dffbf3f6.96ed0042 

New Loar 

i Process VI 
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4/8/1 
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Figure 7-5 Process instances 
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Business Rule Manager 

Check that the business rules can be viewed and edited in the business rule 
manager of the source environment (Figure 7-6). 



Figure 7-6 Business rules 


Chapter 7. Migrating WebSphere Process Server V6.1 .2 to V7.0 on a z/OS system 


347 


Failed events 

Check the failed events from administrative console of the source environment by 
selecting Integration Applications -» Failed Event Manager (you can see the 
results in the window that is shown in Figure 7-7). If possible, all existing failed 
events should be resolved before migration. The number of current remaining 
failed events should be recorded to ensure that there are no failed events lost 
during migration. After migration, the number of failed events should be equal to 
or larger than the current number. One convenient approach to recording the 
failed events is to take a screen capture of all the failed events display pages. 


El Preferences 

Refresh | Get all | Search | Resubmit | Resubmit with trace | Delete | Delete expired eve 

© o)(¥j(¥) 

Select 

Message ID 0 

Type 0 

Src. module 0 Src. component 0 Best, module 0 

n 

355FD953380CC86A. . 
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ITSO_vl 

NewLoanProcess_vl 

ITSO_impl_vl 

n 

_ r _.. 1 355FD953380CC86 A 800000 1 

355FD953380C<W"wtrr ■■■■w.TJ/L.i.Ti- — * . » J vl 

NewLoanProcess_vl 

ITSO_impl_vl 
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ITSO_vl 

NewLoanProcess_vl 
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ITSO_vl 
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NewLoanProcess_vl 
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Figure 7-7 Failed events 
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Check the first one of these failed events (Figure 7-8). 



Figure 7-8 The first failed event 
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Check the business data of the first failed event (Figure 7-9). 



Figure 7-9 The business data of the first failed event 


Note: It is not mandatory to resolve failed events. You can re-submit them 
after migration as well. However, it is best practice to migrate a system in a 
clean state, that is, when there are no failed events before the migration. 


Clean up the exceptions 

Before migration, the SystemOut.log files of all the application servers should be 
checked for any exceptions. You can search for “ E ” (there is one blank character 
both before and after the E) through the log file to find any exception. All runtime 
and application exceptions should be handled accordingly (non-fatal exceptions 
can be ignored on a case by case basis). 

Manually copy third-party artifacts 

We did not use third-party artifacts in our migration source environment. If you 
have used third-party artifacts, you need to manually copy them to the migrated 
environment again. See 3.4.2, “Runtime migration for network deployment with 
cluster” on page 99 for more information. 

Stop the source environment 

For a full downtime migration, we need to stop the whole source environment 
before starting the migration procedure. You should first stop the application 
servers, then stop the node agents, and then stop the deployment manager. 

Back up the source environment 

Before the actual migration steps, back up the source environment, including the 
runtime environment and all of the product databases and user databases on 
z/OS. This backup is critical for performing a rollback in case there is a migration 
failure. 
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7.2 Installing WebSphere Process Server V7.0 on z/OS 

Before you start migrating the source deployment environment, you need to 
create the WebSphere Process Server V7.0 target profiles that have the same 
type as the ones on z/OS. In this sample, we need to create the Version 7.0 
deployment manager and two empty nodes on z/OS. 

For instructions about how to create the profiles on z/OS, refer to Chapter 3, 
“Creating the WebSphere Process Server deployment manager and two empty 
nodes”, in z/OS: WebSphere Business Process Management 1/7 Production 
Topologies, SG24-7831 . 

Before the actual migration steps, back up the target Version 7.0 profiles on 
z/OS. This backup is critical for performing a rollback in case there is a migration 
failure. 


Note: 

► There is a fundamental difference between the distributed process and the 
z/OS migration process, because the target cell comprised of profiles of 
the same type must be created before migration. 

► Use the same cell name and node name of the source when creating the 
target profiles. If you use different cell and node names, federated nodes 
cannot successfully migrate to the Version 7.0 cell. 

► You can use the Version 6.1.2 databases for the target profiles, or you can 
create new databases. Although re-using the Version 6.1.2 databases in 
the target environment is generally preferred, it might be a good time to 
re-organize your DB2 databases for performance reasons. In this 
document, we re-used the Version 6.1.2 databases. 

► Use the same procedure names for the daemon and controller regions 
when creating the target deployment manager. 

► Use the same procedure names for the daemon, adjunct, controller, and 
servant regions when creating the target empty managed nodes. 

► Simply create the target profiles of the deployment manager and empty 
managed nodes. Do not start and federate them. 
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7.3 Migrating the runtime environment 


This section provides the instructions needed to migrate the existing topology 
from Version 6.1 .2 to Version 7.0 on z/OS. 


7.3.1 Migration steps overview 

Figure 7-10 lists the typical steps to migrate the WebSphere Process Server 
V6.1 .2 cell to Version 7.0. 



Figure 7-10 Migration overview steps 
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7.3.2 Migrating the deployment manager 


The deployment manager profile must be the first profile to be migrated. It must 
be migrated before the migration is attempted on the managed nodes. During the 
migration of the deployment manager profile, the applications (user applications, 
system applications, support applications, and the sample applications) and the 
deployment environment configuration data (clusters, JMS resources, database 
resources, and so on) are transformed and copied to the target profile. The target 
profile is the new Version 7.0 deployment manager profile. 

The source and target deployment manager profiles for this example are shown 
in Table 7-1. 


Table 7- 1 Deployment manager migration 


Source server 

Target server 

/was61 conf ig/l 1 cell/l 1 dmnode 

/was70config/H cell/11 dmnode 


In this section, you use the migration jobs to perform the migration on the 
deployment manager. The deployment manager profile in Version 6.1.2 is 
migrated to the deployment manager profile in Version 7.0. After the migration, 
the Version 6.1 .2 deployment manager should not be started. 

The steps to migrate the deployment manager profile are: 

► Generate the WebSphere Application Server migration jobs 

► Edit and submit the migration job BPZWMG3D 

Generate the WebSphere Application Server migration jobs 

The first step to migrate a profile on z/OS is to generate the WebSphere 
Application Server migration jobs and variables from the z/OS Migration 
Management Tool (MMT) component of the WebSphere Customization tools 
(WCT). 

At this point, we assume that you have installed WCT V7.0 or later and you have 
verified that it starts. 


Note: You can download WebSphere Customization Tools V7.0 from the IBM 
Support website at the following address: 

http : //www-01. ibm.com/support/docview.wss?rs=180&uid=swg24020368 


Now we can begin the discussion of how to use the MMT to customize the 
WebSphere Application Server migration utility jobs. 
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Create migration location 

A migration location is where the MMT will store the results of the migration job 
customization work you do. The location can be on a local hard drive or a 
network drive. You can create a new location or tell the tool to use an existing 
one. In this example, we show how to create a new location. 


Perform the following steps: 

1 . Launch WCT V7.0. To open the z/OS MMT component, if you see the z/OS 
Migration Management Tool tab, click it; otherwise, select Window Open 
Perspective -» Other. The window shown in Figure 7-11 opens. 



Figure 7-11 Open Perspective window 
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2. Select z/OS Migration Management Tool and click OK. The z/OS MMT 
window opens, as shown in Figure 7-12. 



Figure 7-12 z/OS Migration Management Tool 


3. In the Migration Locations section, click Add... (Figure 7-13). 
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Figure 7-13 Launch the Add Migration Location window 
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4. In the Add Migration Location window, enter the information shown in 
Figure 7-14. 



Figure 7-14 Add Migration Location window 

- You have two choices for a location: Add an existing location or create a 
new one. Selecting Add an existing migration location assumes that the 
directory exists and is already populated with WCT information. Selecting 
Create a new migration location initializes a new location, either an 
empty directory you point to or a new directory that the WCT creates for 
you. In this example, we select Create a new migration location. 

- The name of the location is what will be displayed in the tool. It should be 
something meaningful to you. For example, ZCELL refers to the cell being 
migrated on z/OS. Inside the ZCELL location are the definitions for the 
nodes in ZCELL being migrated. 

- For the version number, select 7.0. 

- The location is the actual path on the storage device (local drive or 
network drive) where WCT will save the migration definitions. The 
directory might already exist, but it must be empty. You may name a new 
folder and the WCT will create it for you. Here we define a new directory 
named D:\zOS\ZCELL. 

Click Finish. 
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Note: 

► The Version 7.0 WCT now has a locking mechanism that allows a 
location to be used by multiple people. 

► Locations should be in a place other than the installation path for the 
WCT itself. This configuration prevents the accidental loss of definitions 
if the WCT is uninstalled and someone deletes the whole folder 
structure. 


5. Now you should see the new location you just created (Figure 7-15). There 
should be no definitions in the list because the location is new. 



Figure 7-15 Migration location is created 


Note: If you had a different cell, for example, ACELL, you might consider 
creating a separate location for it. You could keep both cells in one 
location, but it might cause confusion. Different locations allow you to 
organize your definitions into logical groups. 
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Create the migration definition for the deployment manager 

After the location is created, you can begin the process of creating the migration 
definition for the deployment manager. A migration definition is what holds all the 
information about one node being migrated, as well as all the generated 
components (such as the actual batch jobs) for the migration utilities. 

Migration is a node-by-node process. Each node requires its own migration 
definition. A cell with three nodes will require three migration definitions. In this 
section, we create the migration definition for the deployment manager. The 
migration definitions for the two managed nodes will be created later in 7.3.5, 
“Migrating the primary node” on page 387 and 7.3.6, “Migrating the secondary 
node” on page 415. 

Perform the following steps to create the migration definition for the deployment 
manager: 

1 . Make sure that your new location is highlighted in the Migration Locations 
section. 

2. Click the Migrate button in the Migration Definitions section. A window that 
looks like Figure 7-16 opens. 



Figure 7-16 Select the type of node to be migrated 
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This window shows the three types of nodes that can be migrated: 

- Standalone: The node within a cell that consists of a single application 
server only; there is no deployment manager or node agent that part of the 
cell. This is not a Network Deployment cell. 

- Deployment manager: The deployment manager node that is part of a 
Network Deployment cell. 

- Federated node: A managed node in a Network Deployment cell that has 
been federated into the DMGR cell. 

Select z/OS migrate a deployment manager and then click Next. 

3. Provide a definition name and, optionally, a response file (Figure 7-17). 



Figure 7-17 Migration definition name window 

- The definition name displays in the list of Migration Definitions within the 
selected location. It can be whatever is meaningful to you. Blank spaces 
are not allowed. We use the definition name of DMGRNODE. 
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- A response file is a flat file of variable name/value pairs that are used to 
populate the input fields for a definition. Response files are optional; if you 
do not have one, it simply means that you supply the information manually. 
Here we left it blank and completed all the fields manually. After we 
supplied all the inputs and saved the deployment manager definition, the 
MMT produces a response file in the migration location 
D:\zOS\ZCELL\profiles\DMGRNODE.ADMGRNODE.responseFile, where Xis 
the number of the modification). 

Click Next. 

4. Provide the high-level qualifier for that z/OS data sets that will hold the 
generated jobs and instructions from the MMT (Figure 7-18). 



Figure 7-18 Specify target data sets to store generated jobs 

We enter the high-level qualifier WPSCFG.MIGDMGR, which results in the 
following data sets being used: 

- WPSCFG.MIGDMGR.CNTL 

- WPSCFG.MIGDMGR. DATA 

The generated jobs and instructions from the MMT are uploaded to the above 
two partitioned data sets on z/OS. 
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5. Next, we specify the system proc library and the location of the WebSphere 
Application Server V7.0 SMP/E file system (Figure 7-19). 



Figure 7-19 Data Set Names and Product Directory window 

- Specify the procedure library you want the copy job to use when copying 
the new JCL. We specify the JCL procedure library of SYS1 .PROCLIB. 

- We use the WebSphere Application Server product directory 
/usr/lpp/zWebSphereL2/V7.0R0 in ourz/OS installation. This provides the 
migration utility with knowledge of where the WebSphere Application 
Server V7.0 SMP/E product file system is located. 

We select Create intermediate symbolic link and give it the path name 
of /was70conf i g/1 lcel 1 /I ldmnode/1 ldmnode_wassmpe. 

We give it an intermediate symbolic link to provide each node the ability to 
be moved to a new level of maintenance. 
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For more information about this topic, search for WP1 00396 at the 
following address: 

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP10 

0396 

In short, an intermediate symbolic link is a symlink you create that points 
to the actual WebSphere Application Server V7.0 SMP/E product file 
system. That provides an “alias” for the actual location. 

Click Next. 

6. Figure 7-20 shows the job that allocates and mounts the file system that will 
hold the Version 7.0 deployment manager’s migrated configuration. 



Figure 7-20 File system configuration for Version 7.0 deployment manager 

- The mount point should be the new Version 7.0 deployment manager’s 
configuration file system, not the “from” Version 6.1 .2 mount point (that 
mount point is used later). We use the value 
/was70config/H cell/11 dmnode. 
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- We use the actual data set name of 

OMVS.WAS70.L1 CELL. LI DMNODE.ZFS for the Version 7.0 deployment 
manager’s configuration. 

- We use the actual volume name of TSTO 68 for the Version 7.0 
deployment manager’s configuration. 

- The primary and second allocation values should be set to correspond 
roughly to your current configuration file system’s size and allow for future 
growth. In our example, we use 1100 and 100 cylinders, respectively. 


Note: The primary allocation of 420 cylinders should be the minimum 
value. Check the actual size of your current node file system and adjust 
this value accordingly, taking into account any anticipated growth in 
applications in the future. 


- Select the file system type you use. We use ZFS in our example. 
Click Next. 
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7. Figure 7-21 , along with Figure 7-22, shows the bulk of the migration 
information. 



Figure 7-21 Server customization for deployment manager migration: Part 1 

- For the deployment manager’s “from” mount point, we use the value of 
was61config/H cell/11 dmnode, where the WebSphere Process Server 
V6.1 .2 deployment manager is located. This is where the migration utility 
will go to read in the existing Version 6.1 .2 configuration that will be 
migrated. 

- The “to” mount point is where the migration utility will write the migrated 
configuration for Version 7.0. The mount point field is greyed-out, and is 
based on the value you supplied in Figure 7-20. 
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- The default home directory, DeploymentManager, is used for both the 
“from” and “to” configuration location. We left this value unchanged. 

- We need provide the JCL V7.0 start procedure names, including the ones 
for the daemon, controller, and servant procedures for the deployment 
manager. In Version 6.1 .2, the names for the daemon, controller, and 
servant procedures of the deployment manager are LI DEMN, LI DCR and 
LI DSR, respectively. 

In this example, we re-use the same JCL start procedure names for the 
Version 7.0 deployment manager. Clearing the check box means that the 
migration utility will not replace the START strings held in the configuration 
XML. 

Because we re-use the same JCL start procedure names, we cleared 
Replace started procedure command names. The Version 7.0 start 
procedures have a different format than Version 6.x, so the old Version 
6.1.2 procedures need be overwritten. Before starting the migrated 
servers, the *CPY1 job need to be executed to overlay the existing JCL 
start procedures in your JCL procedure library. This step will be performed 
in 7.3.4, “Start the deployment manager” on page 386. 

- When migrating a deployment manager node, the migration utility attempts 
to make contact with the dmgr process. The utility needs to know the user 
ID and password that will allow it access: 

• If global security is off for the cell, then this value is not required to do 
the migration, but the MMT requires the ID field and the password 
fields to be populated. You may take the defaults just to satisfy the 
requirement to fill the fields. 

• If security is enabled, then provide a valid ID and password for 
accessing the dmgr process. 


Note: The password value is encrypted in the files that are created, 
both in the MMT tool and in the uploaded job files. 
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g. Click Next. The window shown in Figure 7-22 opens. 



Figure 7-22 Server customization for deployment manager migration: Part 2 
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Where: 


- The Migrate to support script compatibility check box determines whether 
the migrated configuration will be backwards compatible with the earlier 
versions of the WSADMIN scripting interface. We cleared it because we 
did not have scripts with compatibility issues. 

- It is a good idea to disable the old dmgr process after migration is 
successfully completed. We did not have the migration utility disable this 
process. 

- For Application migration preference, we took the default here. If you 
believe your applications are installed somewhere other than default, then 
you should review the options and make the selection best suited for your 
environment. 

- For Migration trace options, we left all boxes clear. Check these boxes only 
when directed to do so by IBM Support.The trace options produce 
significant amounts of output. 

- For migrating the My tasks settings, we used the default. We had no 
previous “My Tasks”. 

- The temporary directory location is where the migration utility will create 
the temporary files it needs during the migration run. We create a separate 
directory named /was70config/l lmi grate/temp that is distinct from the 
system / tmp directory, and allocated and mounted a file system at that 
location that was 1 .5 times the current size of the node’s configuration file 
system. We made sure that the permissions on this directory were 777. 


Important: 

► Depending on the size of the configuration, the migration utility might 
need up to 500 cylinders of temporary space. Allocate and mount a 
temporary file system of that size and point to that location in this 
field. 

Lack of space is one of the most common causes of migration job 
failure. 

► If you are performing multiple migrations, or rerunning a migration, 
remember to clean out the temporary directory so you have the 
maximum space available to you. 


Chapter 7. Migrating WebSphere Process Server V6.1 .2 to V7.0 on a z/OS system 367 




8. In Figure 7-23, you can create the JOB card that will be used in the generated 
jobs. You should change this card to conform with your normal procedures. 
Figure 7-23 is the JOB card used in our z/OS system. 



Figure 7-23 JOB card for the generated jobs 
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9. Figure 7-24 shows the migration summary. Click the Create button to create 
the migration definition. 



Figure 7-24 Migration summary for the deployment manager 
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10. The migration definition for the deployment manager is created successfully, 
as shown in Figure 7-25. Click Finish. 



Figure 7-25 Migration definition is created successfully 

Process (upload) the definition to z/OS 

This step transfers the generated customized jobs for migrating the deployment 
manager from the MMT tool on your workstation up to the z/OS system where 
they will be run. To accomplish this task, perform the following steps: 

1 . Select the DMGRNODE definition we just created and click the Process 
button. 
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2. Select the option to upload to z/OS (Figure 7-26). 



Figure 7-26 Select upload option 
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3. Provide the p 
(Figure 7-27). 


n the upload to z/OS to succeed 



Figure 7-27 Provide parameters for upload jobs 

- Provide the host IP name of the system on which the jobs will be run. 

- Provide a user ID and password for the FTP upload. 

- Modify the port if you know your system uses something other than 21 for 
FTP. 

- Check Allocate target z/OS data sets (leave it clear if you are 
pre-allocating manually) 

- Specify the volume and unit if you desire; otherwise, leave it blank. 
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Click Finish. 


4. Watch the progress bar (Figure 7-28). 



Figure 7-28 The progress bar 

5. Look for the “Upload successful” message (Figure 7-29). 



Figure 7-29 Upload successful 
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6. You should see the MMT main window again. The customized migration jobs 
for the deployment manager should now be on the z/OS system and be ready 
to be submitted. We validate that the data sets have been created and that 
they contain the expected member. Figure 7-30 shows the CNTL data set. 


VIEW WPSCFG . MIGDMGR . CNTL 

Command ===> 

Name Prompt Size 

BBOMDCP 

BBOMDCR 

BBOMDDN 

BBOMDHFS 

BBOMDINS 

BBOMDSR 

BBOMDZFS 

BBOSCHED 

BBOWDPOS 

BBOWDPRE 

BBOWDPRO 

BB0WMG3D 

**End** 


Figure 7-30 The data sets contained the generated migration jobs 

Edit and submit the migration job BPZWMG3D 

After the migration jobs and variables are generated and uploaded by the z/OS 
MMT tool, we can edit the sample WebSphere Process Server migration job 
BPZWMG3D to make use of these WebSphere Application Server migration 
jobs. 

After the BPZWMG3D job is submitted, it executes the wbimgrt2.sh script, which 
invokes the migration utilities BPMSnapshotSourceProfile.sh and 
BPMMigrateProfile.sh to migrate the WebSphere Process Server V6.1 .2 
deployment manager to Version 7.0. 

Perform the following steps: 

1 . Find the sample migration job BPZWMG3D in the installed WebSphere 
Process Server JCL PDS (,**.SBPZJCL). In our z/OS system, it is located in 
BBL27061 .SBPZJCL PDS. Copy it to your working PDS. In this sample, we 
used WPSCFG.WPS.JCL as the working PDS. 

2. Edit the copy of the sample job BPZWMG3D to make use of the WebSphere 
Application Server migration jobs generated by MMT: 

a. Add a JOB card for the BPZWMG3D job, making sure that you use the 
administrator user ID and password. 
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Example 7-1 shows the JOB card we used in our z/OS. 
Example 7- 1 JOB card for the BPZWMG3D job 


//BPZWMG3D JOB NOTIFY=&SYSUID,CLASS=A,MSGCLASS=H, 
// REGI0N=0M,TIME=1440, 

// USER=L1ADMIN, PASSW0RD=L1ADMIN 

/*J0BPARM S=SC61 

//* 


b. Replace the parameters shown in Example 7-2 to reflect the deployment 
manager configuration and the parameters entered in MMT. 


Example 7-2 Parameters to be replaced in BPZWMG3D job 


//* 

ftempdi r# 

temporary working directory 

* 

//* 


eg. V7 .OOdml 

* 

//* 


V7.00DMGR 

* 

//* 



* 

//* 

Iwpsndi r# 

directory of the V7.0.0 WPS product 

* 

//* 


eg. /usr/1 pp/zWPS/V7.0R0 

* 

//* 


/usr/lpp/zWPSL2/V7.0R0 

* 

//* 



* 

//* 

Iwpsosvr# 

home directory of the old wps server 

* 

//* 


eg. /WebSphere/V62DMl 

* 

//* 


/was61conf i g/1 lcel 1 /I ldmnode 

* 

//* 



* 

//* 

Iwpsnsvr# 

home directory of the new wps server 

* 

//* 


eg. /WebSphere/V7 .00DM1 

* 

//* 


/was70conf i g/1 lcel 1 /I ldmnode 

* 

//* 



* 

//* 

Iwassmpe# 

dir of the WAS smpe install 

* 

//* 


eg. /usr/1 pp/zWebSphere/V7.00P4098 

* 

//* 


/usr/1 pp/zWebSphereL2/V7 . 0R0 

* 

//* 



* 

//* 

fprocdmn# 

name of the started task procedure (daemon) 

* 

//* 


eg WDDM1Z1 

* 

//* 


L1DEMN 

* 

//* 



* 

//* 

fprocctr# 

name of the started task procedure (control) 

* 

//* 


eg WCDM1Z1 

* 

//* 


L1DCR 

* 

//* 



* 

//* 

fprocsvr# 

name of the started task procedure (servant) 

* 

//* 


eg WSDM1Z1 

* 

//* 


L1DSR 

* 
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//* 



* 

//* 

Imigrpds# 

hlq of pds of migration jobs created by WebSphere 

* 

//* 


Customisation panels. 

* 

//* 


eg. ZWPS.WAS. V7 .00. V7 .00DM1 .MIG 


//* 


WPSCFG.MIGDMGR 

* 

//* 



* 

//* 

Itouserid# 

if security is switched on in the old wps server 

* 

//* 


then supply the userid. 

* 

//* 


eg. wsadmin 

* 

//* 


lladmin 

* 

//* 



* 

//* 

Itopswd# 

if security is switched on in the old wps server 

* 

//* 


then supply the password. 

* 

//* 


lladmin 

* 


3. Submit the edited BPZWMG3D job (Figure 7-31). 


VIEW WPSCFG.WPS. JCL(BP2WMG3D) - 01.12 Columns 00001 00072 

Command ===> submit_ Scroll ===> PAGE 

****** ***************************** Top of Data ***************************** 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 / /BPZWMG3D JOB N0TIFY=8,SYSUID,CLRSS=fl,MSGCLRSS=H , 

000002 // REGION=OM,TIME=1440, 

000003 // USER=LlflDMIN,PRSSWORD=LlfiDMIN 
000004 /jkJOBPRRM S=SC61 
000005 //* 

000006 //********************************************************************* 
000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp. 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclose 
000011 //* restricted by GSR RDP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive 
000013 //* of its trade secrets, irrespective of what has been deposited with 
000014 //* U.S. Copyright Office. 

000015 //********************************************************************* 

Figure 7-31 The BPZWMG3D job 

After the job is submitted, it executes the wbimgrt2.sh script, which invokes 
the migration utilities BPMSnapshotSourceProfile.sh and 
BPMMigrateProfile.sh. These utilities migrate the WebSphere Process Server 
V6.1 .2 deployment manager to Version 7.0. 
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The migration of a source profile consists of two steps in the following 
sequence: 

a. Take a backup of the source profile to the snapshot directory 

(Figure 7-32). The BPMSnapshotSourceProfile.sh command will be 
executed to take the snapshot of the deployment manager profile in the 
source environment. 

The snapshot directory on z/OS is /tmp/migrat e/#tempdir§, where 
#tempdir# is the parameter you defined as V7.00DMGR in step 2b on 
page 375 (see Example 7-2 on page 375). 



Figure 7-32 The snapshot directory 

b. Migrate the source profile to the target profile. The BPMMi grateProf i 1 e . sh 
command will be created to migrate the source profile to the target profile. 
4. Examine the output in /tmp/migrate/#tempc/ir#/BPZWMG3D.out and 

/tmp/migrate/#tempdir#/dmgr_backup/logs (Figure 7-33) to make sure the 
migration completed successfully. 


Ri dS Hi •' Qj 1 X |/tmp/ migrate/ V70DMGR/ dmgr_backup/logs | Add 

Remote Name > I Size I Type 

0 BPMMi grateProfile. default. Fri-Apr-16-14. 11. 06-EDT-2010. log 14, 828 XTS® 

|® BPMProfilelfpgrade. default. Fri-Apr-16-14. 30. 48-2010. log 55, 5T6 

g| BPMFrof ileUpgrade. default. Fri-Apr-16-14. 30. 48-2010. trace 1, 204, 684 TRACE JCft 

0 BPMSnapshotSourceProfile. default. Fri-Apr-16-14. 02. 2T-EDT-2010. log 13, 669 JCSSt® 

gWASPostUpgrade. default. Fri-Apr-16-14. 11. 06-EBT-2010. trace 26, 853 TRACE Stt 

® WASPostUp grade, default. Fri-Apr-16-14. 11. 14-2010. log 84, 097 

g WASPreUp grade, default. Fri-Apr-16-14. 02. 30-EBT-2010. trace 3, 080 TRACE JCtt 

® WASFreUpgrade. Fri-Apr-16-14. 02. 38-2010. log 427, 407 


Figure 7-33 Logs created for deployment manager migration activity 
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a. Step 3a on page 377 creates the following log files in the logs subdirectory 
of the snapshot/dmgr_backup directory: 

• BPMSnapshotSourceProf i 1 e . defaul t .Time_Stamp . 1 og . 1 ck 

• BPMSnapshotSourceProf i 1 e . defaul t . T ime_Stamp . 1 og 

• WASPreUpgrade. defaul t .Time_Stamp .trace 

• WASPreUpgrade.Time_Sfamp.log 

You can examine these logs to monitor the progress of the snapshot 
activity. The 1 og. 1 ck file is a lock file to indicate an instance of an activity 
taking a snapshot of the deployment manager profile that is already 
running. This mechanism prevents starting multiple snapshot activities 
inadvertently by different users. 

When step 3a on page 377 is finished, you should see the output shown in 
Example 7-3 in BPMSnapshotSourceProfile.default.7ime_Sfamp.log. 

Example 7-3 Output for snapshot activity 

[4/16/10 2:10:27 PM EDT] 0 Fi 1 eUti 1 i ties > serial izeObject 
ENTRY 

{/SC61/tmp/mi grate/V7 .00DMGR/dmgr_backup/prof i 1 es/def aul t/defaul t 
.profinfo} 

[4/16/10 2:10:27 PM EDT] 0 Fi 1 eUti 1 i ties < serial izeObject 
RETURN 

[4/16/10 2:10:27 PM EDT] 0 BPMSnapshotNode < invokeAdditionalMigr 
RETURN 

[4/16/10 2:10:27 PM EDT] 0 WBIUpgradeBase < migrate 
RETURN 

[4/16/10 2:10:27 PM EDT] 0 BPMSnapshotNode I main(String[] args) 
CWMC00823I : The BPMSnapshotSourceProf i le command finished 
successful ly. 


b. The logs for step 3b on page 377 are also created in the logs subdirectory 
of the snapshot/dmgr_backup directory. You can watch these logs to see 
the progress and results. 

• BPMMi grateProf i 1 e. defaul t .Time_Stamp . 1 og 

• BPMProf i 1 eUpgrade. defaul t .Time_Stamp . 1 og 

• BPMProf i 1 eUpgrade . defaul t . T ime_Stamp .trace 

• WASPostUpgrade . defaul t . T ime_Stamp . trace 

• WASPostUpgrade . defaul t . T ime_Stamp . 1 og 
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c. After both steps complete successfully, check the output in 

/tmp/migrate/#tempdir#/BPZWMG3D.out. You should see the output in 
BPZWMG3D.out (Example 7-4). 

Example 7-4 Output in BPZWMG3D.out 


STEP: MKCONFIG 


Validation of Environment Completed... 


STEP: PREUPGRD (BPMSnapshotSourceProfi 1 e) 


CWMC00224I : The WebSphere Application Server utility has 
completed. 

CWMC00208I : See the following log file for information: 
/SC61/tmp/migrate/V7.00DMGR/dmgr_backup/logs/WASPreUpgrade.<TIMES 
TAM P>. log 

CWMC00823I : The BPMSnapshotSourceProfi le command finished 
successful ly. 


STEP: UPGRADE (BPMMigrateProfile) 


CWMC00224I : The WebSphere Application Server utility has 
completed. 

CWMC00208I : See the following log file for information: 

/SC61/tmp/migrate/V7.00DMGR/dmgr_backup/logs/WASPostUpgrade.defau 

lt.<TIMESTAMP>.log 

CWMC00822I : The BPMMigrateProfile command finished successfully. 
Migration Completed Successfully... 
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5. Check the BPZWMG3D job status via SDSF in a TSO session (Figure 7-34). 

GC - 20090817_AA, Java Compiler = j9jit24, Java VM name = IBM J9 VM 
was. install. root = /was70conf ig/llcel 1/1 ldmnode/Deploymen tManager 
user . instal 1 . root = null 

Java Home = /SC61/zWebSphereL2/ j ava/J6 . 0 

ws. ext . dirs = /was70conf ig/llcel l/l ldmnode/Deploymen tManager/ java/1 ib: /was"? 
Classpath = /was70con f ig/1 lcel l/l ldmnode/Deploymen t Manager/proper t ies : /was"? 
Java Library path = /SC61/zWebSphereL2/ j ava/J6 . 0/1 ib/s390 : /SC61/zWebSphereL 
Current trace specification = *=info 

************* End Display Current Environment ************* 

7/16/10 14:34:58:514 EDT700000000 ManagerAdmin I BBOO0222I: TRAS0017I: 1 


Migration Completed Successfully. 


Figure 7-34 The BPZWMG3D job status 
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6. Check if the applications (user applications, system applications, support 
applications, and sample applications) have been copied to the target profile 
(Figure 7-35). 


gj ^ fit X 1/ was70config/l Icell/lldmnode/DeploymentManager/ profiles/default/ conflg/ cells/l Ice ▼ | Add 

Remote Name 

Size Type 

Modified 

1 Attributes 

PilAppSchednler. ear 

Folder 

2010-04-16 13:1... 

drwxrw. . . 

£2)BPCExplorer_llcl01. ear 

Folder 

2010-04-16 13:1... 

drwxrw. . . 

£3BPEContainer_llcl01. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

\r^ Bus i ne s sRul e sM anager . ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

(^(cbebrowser. ear 

Folder 

2010-04-16 13:3... 

drwxrw. . . 

ICjBefaultApplication. ear. ear 

Folder 

2010-04-16 13:3... 

drwxrw. . . 

|^| Events ervice. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

^jfiletransfer. ear 

Folder 

2010-04-12 15:3... 

drwxrw. . . 

l2|Him_PredefinedTaskfflsc_V61. . . 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

|^| HTM_Pr e de f i nedT asks_V6 1 2_. . . 

Folder 

2010-04-16 13:1... 

drwxrw. . . 

igjisdite. ear 

Folder 

2010-04-12 15:3... 

drwxrw. . . 

l2)nS0_impl_vlApp. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

ITS0_m e d_vl App . ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

lS)ITSO_vlApp. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

If^lpersistentLMIgr. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

glRemoteALBl. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

t3)REST Services Gateway Bmg. . . 

Folder 

2010-04-14 20:1. . . 

drwxrw. . . 

Ir^sca. sib. mediation, ear 

Folder 

2010-04-16 13:1... 

drwxrw. . . 

IrUTaskContainer llclOl. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 

QWebSphereWSBU. ear 

Folder 

2010-04-12 15:3... 

drwxrw. . . 

£3)wpsFEWgr_6. 1.2. ear 

Folder 

2010-04-16 13:2... 

drwxrw. . . 


Figure 7-35 Applications copied into the target profile 
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7.3.3 Upgrading the common database 


This procedure can be done manually or by using the Dbdesign generator and 
upgradeDB.sh scripts. In our example, we update it manually by performing the 
following steps: 

1 . Locate the directory that contains the migration upgrade scripts for the 
common database. These scripts are generated in database-specific 
directories within the dbscri pts directory of the target deployment manager. 
In this example, the common database version we used was DB2 z/OS V9, 
and the directory where these migration upgrade scripts are located is 
/was70conf i g/1 lcel 1 /I ldmnode/wpssmpe/dbscri pts/ComrnonDB/DB2zOSV9/ 
(Figure 7-36). 


S {3 Si T' Sf [f wpssmpe/ dbscripts/CommonDB/DB2zOS V9 -■ | 

Remote Name 

Size 

Type 

ID resetTables_DirectDeploy. sql 

595 

SQL . . . 

2 up gr adeS chem a£0 1 DB2 zOSV7 . sql 

2,125 

SQL . . . 

2 up gradeS chem a602_CommonIlB. sql 

2,274 

SQL . . . 

12 up gr adeS chem a602_customi ration. sql 

1,741 

SQL . . . 

2 up gr adeS chem a602_D ir e c tD epl oy . sql 

3,743 

SQL . . . 

2 upgradeSchema602_governancerepository. sql 

18, 237 

SQL . . . 

2 up gr adeS chem a602_r el at i onshi pS er vi c e . sql 

1,844 

SQL . . . 

2 upgradeSchema602DB2i0SVT. sql 

2,402 

SQL . . . 

2 up gr adeS chem a6 10_C omm onDB . sql 

2,274 

SQL . . . 

2 upgradeSchema610_DirectDeploy. sql 

3,743 

SQL . . . 

2 up gr adeS chem a6 10_governanc erepository. sql 

18, 237 

SQL . . . 

2 upgradeSchema610_relati onshi pService. sql 

1,111 

SQL . . . 

2 upgradeSchemaS10DB2z0SV7. sql 

2,408 

SQL . . . 

2 up gradeS chem a612_C omm onDB. sql 

2,274 

SQL . . . 

2 up gr adeS chem a612_Dir ectD epl oy. sql 

3,743 

SQL . . . 

2 upgradeSchema612_governancerepository. sql 

18, 237 

SQL . . . 

2 upgradeSchema612_relationshipService. sql 

1,112 

SQL . . . 

2 up gr adeS chem a620_C omm onBB . sql 

2,274 

SQL . . . 

2 up gr adeS chem a620JD ir e c tD epl oy. sql 

468 

SQL . . . 

2 up gr adeS chem a620_go vernanc erepository. sql 

11,073 

SQL . . . 

(3 jwb i s er ver _up gr adeS chem a6 1 2_Re c over y. s ql j 

921 

SQL . . . 


Figure 7-36 The SQL scripts for a common database 
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2. In the directory, look for any SQL files that contain the name upgrade, the 
version number of the source server 612, and wbi . We found five SQL files in 
total in this directory, which will be used to upgrade the common database 
(Example 7-5). 

Example 7-5 SQL files for the common database migration 

upgradeSchema612_CommonDB.sql 
upgradeSchema612_Di rectDepl oy . sql 
upgradeSchema612_governancerepository.sql 
upgradeSchema612_rel ati onshi pServi ce . sql 
wbi server_upgradeSchema612_Recovery . sql 


3. Edit the values in the SQL files to suit your needs. Replace the following 
parameters of the common database according to the actual database 
configuration. Example 7-6 shows the parameters we used in our z/OS. All 
the parameters in @*@ have been replaced with the actual values of the 
common database configuration. 


Example 7-6 Parameters replaced in the SQL files to upgrade the common database 


— @DB NAME@ 

= DB2 Database name 

= L1CELLDB 

— 0SCHEMA0 

= DB2 SQLID (Schema Qualifier) 

= L1CELL 

— 0STOGRP0 

= DB2 Storage group name 

= L1DBST0 

— 0BPTABLE4K0 

= Buffer Pool of 4k Size 

= BP1 

— 0BPINDEX0 

= Buffer Pool Index 

= BP2 

— 0BPLOB4K0 

= Buffer Pool Lobs 

= BP3 


4. Save the SQL files you have edited. Because the DBUtil ity.sh command will 
be used to execute these SQL files and it uses ASCII input, you do not need 
to convert these SQL files from ASCII to EBCDIC. 

5. Copy the SQL files to your working directory, for example, 
/u/<username>/Migration/DB/, and assign the appropriate permissions. 
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6. Create five scripts to execute the above five SQL files. In these scripts, the 
SQL file is executed using the DBUtility.sh command. The command 
parameters for DBUtil ity.sh createTable are shown in Figure 7-37. 


"createTable" is the action, following args ate needed: 

-DprofilePath=<profilePath> The path of profile 

-DprofileName=<profileWame> The name of the profile 

-DdbDelayConf ig=<boolean> The Flag is to be false to create Tables 

-DdbType=<dbtype> The database type 

-DdbName=<dbName> The database name or alias name 

-DsqlScriptPath. default=<defautlSqlPath> 

The default sql script for creating table 
Disutility will attempt to find sql script for each database type 
in this naming convention <defautlSqlPath>_<dbType>.sql. 

Disutility will run <defautlSqlPath>, 
if <defautlSqlPath>_<dbType>. sql does not exist. 
-DsqlScriptHame.default=<defautlSqlScriptHame> 

The default sql script for creating table 
DBUtility will attempt to form a sql script path for each database 
in this naming convention <defautlSqlScriptHame>_<dbType>. sql. 
DBUtility will run <defautlSqlScriptHame>, 
if <defautlSqlScriptName>_<dbType>.sql does not exist. 
-DdbHostName=<dbHostMame> The host name or IP address for database server 
-DdbServerPort=<dbServerPort> The JDBC port number for database server 
-D db JDB C C 1 as sp ath=< db JDBC Cl as sp ath> 

The directory path which contains JDBC driver files 
-DdbUserId=<dbUserId> The user id to access database 

-DdbPassword=<dbPassword> The password to access the database 

-Ddblnstance=<dblnstance> The database instance name — only required for Informix 

-DdbSchemaName=<dbSchemaName> The schema name 
-DdbConnectionLocation=<dbConnectionLocation> 

The database connection location — only required for zOS 
-D db S to r age Gr oup =< db 3 to r age Gr oup> 

The database storage group — only required for zOS 
-DdbJDBCProperties=<dbJDBCProperties> 

The directory containing DB2JccConfiguration.properties — only re 

Figure 7-37 The parameters for DBUtility.sh createTable 

The script shown in Example 7-7 was created to execute 
upgradeSchema612_CommonDB.sql against the common database in our 
z/OS system. 

Example 7-7 Script to execute upgradeSchema612_CommonDB.sql 
./DBUtility.sh createTable 

-Dprof i 1 ePath=/was70conf i g/1 lcel 1/1 ldmnode/Depl oymentManager/prof i 1 e 
s/default -DprofileName=default -DdbDelayConfig=fal se 
-DdbType=DB2UDB0S390_V9_l -DdbName=DB9K 

-DsqlScriptPath.default=/u/<username>/Migration/DB/upgradeSchema612_ 
CommonDB.sql -DsqlScriptName.defaul t=upgradeSchema612_CommonDB.sql 
-DdbHostName=wtsc61 . i tso . i bm.com -DdbServerPort=38340 
-DdbJDBCCl asspath=/usr/l pp/db2/db9k/db2910_jdbc/cl asses 
-DdbUserId=peisel -DdbPassword=IBMlq2w -DdbSchemaName=LlCELL 
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-DdbConnectionLocation=DB9K -DdbStorageGroup=LlDBSTO 
-DdbJDBCProperties=/etc/db9k 
>/u/<username>/Migration/DB/log/output.out 
2»/u/<username>/Migration/DB/log/error.out 


For the other four scripts, you can just modify the SQL file name in the 
-DsqIScriptPath.default and -DsqIScriptName.default parameters. 

7. Convert the five scripts from ASCII to EBCDIC. You can accomplish this task 
by using code editing software (such as UltraEdit, Notepad++, and so on) or 
by the using the iconv command to convert the file to EBCDIC, as shown in 
Example 7-8. 

Example 7-8 Using the iconv command 

iconv -t IBM- 1047 -f IS08859-1 Seri pt_upgradeSchema612_CommonDB.sh > 
Script_upgradeSchema612_CommonDB_EBCDIC.sh 


8. Put the scripts into the bi n directory of the target deployment manager profile. 
This directory is /was70conf i g/1 lcel 1 /I ldmnode/Depl oymentManager/bi n in 
our environment. Assign the appropriate permissions for them. 

9. Change the working directory in UNIX® System Services to 
/was70config/l lcel 1 /I ldmnode/Depl oymentManager/bi n, and then execute 
the scripts, one at a time. 

10. Check the output of the executing SQL files in 
/u/<username>/Mi grati on/DB/1 og/output . out and 
/ u/<username>/H'\ grati on/DB/1 og/error. out. 

The output of upgradeSchema612_CommonDB.sql is shown in Example 7-9. 
Example 7-9 Output for executing common database upgrade scripts 
BEGIN COPYRIGHT 

[sql] Executing file: 

/u/<username>/Mi grati on/DB/upgradeSchema612_CommonDB . sql 
[sql] 10 of 10 SQL statements executed successfully 

BUILD SUCCESSFUL 
Total time: 18 seconds 
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7.3.4 Start the deployment manager 


After migrating the deployment manager profile and upgrading the common 
database, you can start the deployment manager in the target environment by 
performing the following steps: 

1 . Before starting the migrated target deployment manager, the start JCL 
procedures in your JCL procedure library need to be updated for the 
deployment manager. Because the Version 7.0 start procedures have a 
different format from Version 6.x, the old Version 6.1 .2 procedures need be 
replaced. 

a. Locate the BBODCPY1 job in the PDS, where the jobs for creating the 
target deployment manager in 7.2, “Installing WebSphere Process Server 
V7.0 on z/OS” on page 351 were stored (Figure 7-38). In our z/OS, we 
found it in the WPSCFG.DMGRV7.0.CNTL PDS. 


VIEW WPSCFG.DMGRV7.CNTL(BB0DCPY1) - 01.00 Columns 00001 00072 

Command ===> submit_ Scroll ===> PftGE 

****** ***************************** Top of Data *****************************: 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BB0DCPY1 JOB (999, POK) , ' WPS SETUP ' ,CLflSS=A,REGION=0M, 

000002 // MSGCLASS=H,NOTIFY=&SYSUID 

000003 /*J0BPflRM S=SC61 
000004 //* 

000005 //C0PY1 EXEC PGM=IEBCOPY 


000006 

000007 

000008 

000009 

000010 

000011 

000012 

000013 

000014 

000015 


//* Copy customized members to the installatii 
//SYSPRINT DD SYS0UT=* 

//INPUT DD DISP=SHR , 

// DSN=WPSCFG.DMGRV7.CNTL 

//OUTPUT DD DISP=SHR,DSN=SYS1 .PROCLIB 

//SYSIN DD * 

C INDD=INPUT,OUTDD=OUTPUT 
S M=((BB0PDMN2,L1DEMN,R)) 

S M=((BB0PDCR,L1DCR,R)) 

S M=((BB0PDSR,L1DSR,R)) 


proclib 


Figure 7-38 The BBODCPY1 job 


b. Submit the BBODCPY1 job (Figure 7-39). Because we use the same JCL 
start procedure names in Version 6.1 .2 and Version 7.0, the BBODCPY1 
job will overwrite the existing JCL start procedures in your JCL procedure 
library. 


JOB BB0DCPY1(J0B23581) SUBMITTED 


Figure 7-39 Submit the BBODCPY1 job 
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c. Wait until the console shows that the BBODCPY1 job has finished 
(Figure 7-40). 


22.43.41 J0B23581 $HASP165 BB0DCPY1 ENDED AT WTSCPLX1 MAXCC=0 CN(INTERNAL) 


Figure 7-40 The BBODCPY1 job finished 

d. Check the BBODCPY1 job status via SDSF in a TSO session 
(Figure 7-41). 


IEB1013I COPYING FROM PDS INDD=INPUT V0L=TST049 DSN=WPSCFG. DMGRV7. CNTL 

IEB1014I TO PDS 0UTDD=0UTPUT V0L=T0TSY1 DSN=SYS1 . PROCLIB 

IEB167I FOLLOWING MEMBER (S) COPIED FROM INPUT DATA SET REFERENCED BY INPUT 
IEB155I L1DCR HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1DEMN HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1DSR HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB1098I 3 OF 3 MEMBERS COPIED FROM INPUT DATA SET REFERENCED BY INPUT 
IEB144I THERE ARE 823 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY OUTPUT 

IEB149I THERE ARE 429 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY 

IEB147I END OF JOB - 0 WAS HIGHEST SEVERITY CODE 

Figure 7-41 Check the BBODCPY1 job status via SDSF 


2. Start the deployment manager in the target environment. 

3. Check for any errors in the server logs. 

7.3.5 Migrating the primary node 

During the migration of the managed node profiles, server specific configurations 
in the source profiles are transformed and copied to the profiles in the target 
environment. Table 7-2 shows the source and target profiles for our migration. 

Table 7-2 Managed node migration 


Source server 

Target server 

/was61conf i g/1 lcel 1 /I lnodea 

/was70conf i g/1 lcel 1 /l lnodea 

/was61conf i g/1 lcel 1 /I lnodeb 

/was70conf i g/1 lcel 1 /I lnodeb 


In this section, we migrate the primary managed node first. Use the WebSphere 
Process Server migration jobs to perform the migration against the primary 
managed node. 
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► During the migration of a managed node, ensure that the target 
deployment manager is running. 

► Managed nodes can only be migrated one at a time. 

The steps to migrate the primary managed node are: 

► Generate the WebSphere Application Server migration jobs 

► Edit and submit the WebSphere Process Server migration jobs 

Generate the WebSphere Application Server migration jobs 

The first step for migrating a managed profile on z/OS is to generate the 
WebSphere Application Server migration jobs and variables from the z/OS MMT 
tool component of WCT. 

Create a migration definition for the primary node 

Perform the following steps to create migration definition for the primary node: 

1 . Launch WCT V7.0 and click the z/OS Migration Management Tool tab. 

2. Make sure your location is highlighted in the Migration Locations section. 
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3. Click the Migrate button in the Migration Definitions section. The window 
shown in Figure 7-42 opens. 



Figure 7-42 Select the type of node to be migrated 

4. Select z/OS migrate a federated node and then click Next. 
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5. Provide a definition name and, optionally, a response file (Figure 7-43). 



Figure 7-43 Migration definition name window 

- The definition name is what will display in the list of Migration Definitions 
within the selected location. It can be whatever is meaningful to you. Blank 
spaces are not allowed. We use the definition name of NODEA in our 
environment. 

- The response file is a flat file of variable name/value pairs that is used to 
populate the input fields of a definition. Response files are optional; if you 
do not have one, it simply means you supply the information manually. 
Here we left it blank and input all the fields manually. 

After we have supplied all the inputs and saved the node definition, the 
MMT produces a response file in the migration location 
D:\zOS\ZCELL\profiles\NODEA.ANODEA.responseFile (X is the 
modification number). 

Click Next. 
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6. Provide the high-level qualifier for z/OS data sets that will hold the generated 
jobs and instructions from the MMT (Figure 7-44). 



Figure 7-44 Specify the target data sets to store generated jobs 

We used the high-level qualifier WPSCFG.MIGNODEA, which results in the 
following data sets being used: 

- WPSCFG.MIGDNODEA.CNTL 

- WPSCFG.MIGNODEA. DATA 

The generated jobs and instructions from the MMT will be uploaded to the 
above two partitioned data sets on z/OS. 
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7. Next, we specify the system proc library and the location of the WebSphere 
Application Server V7.0 SMP/E file system (Figure 7-45). 



Figure 7-45 Data Set Names and Product Directory window 

- Specify the procedure library into which the copy job puts the new JCL. 
We specify SYS1 .PROCLIB. 

- For the WebSphere Application Server product library, we specify 
/usr/lpp/zWebSphereL2/V7.0R0, which provides the migration utility with 
knowledge of where the WebSphere Application Server V7.0 SMP/E 
product file system is located. 

- We select Create intermediate symbolic link and give it the path name 
of /was70conf i g/1 lcel 1 /I ldmnode/1 ldmnode_wassmpe. 

Creating an intermediate symbolic link provides each node with the ability 
to be moved to a new level of maintenance, which provides a kind of “alias” 
for the actual location. 


392 


Version-to-Version Migration to IBM WebSphere Dynamic Process Edition V7 



8. The window shown in Figure 7-46 is used by the job that allocates and 
mounts the file system that holds the Version 7.0 primary node’s migrated 
configuration. 



Figure 7-46 File system configuration for Version 7.0 primary node 

- The mount point should be filled with the new Version 7.0 primary node’s 
configuration file system, not the “from” Version 6.1 .2 mount point. We use 
the value /was70config/H cell/11 nodea in our environment. 

- We use the data set name of OMVS.WAS70.L1 CELL. LI NODEA.ZFS for 
the Version 7.0 primary node’s configuration in our environment. 

- We use the volume name of TST071 for the V7.0 primary node’s 
configuration in our environment. 

- The primary and second allocation values should be set to correspond 
roughly to your current configuration file system’s size and allow for future 
growth. In our environment, we use 1100 and 100 cylinders, respectively. 
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Note: The primary allocation of 420 cylinders should be considered a 
minimum. Check the actual size of your current node file system and 
adjust this value accordingly, taking into account any anticipated growth 
in applications in the future. 


- Select the file system type you use. We use ZFS in our environment. 
Click Next. 

9. Figure 7-47 shows the first of two windows where most of the migration 
information is entered. 



Figure 7-47 Server customization for primary node migration: Part 1 
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- For the primary node’s “from” mount point, we use the value of 
was61config/H cell/11 nodea, where the Version 6.1.2 primary node is 
located. This is where the migration utility will “read in” the existing Version 
6.1.2 configuration that is to be migrated. 

- The “to” mount point is where the migration utility will write the migrated 
configuration for Version 7.0. The mount point field is greyed-out, and is 
based on the value you supplied in Figure 7-46. 

- The default home directory AppServer is used for both the “from” and “to” 
configuration location. We did not change it in our environment. 

- We need to provide the JCL V7.0 start procedure names, including the 
daemon, controller, servant, and adjunct procedures for the primary node. 
In Version 6.1 .2, the names for the daemon, controller, servant, and 
adjunct procedures of the primary node are L1DEMNA, L1ACRA, 
L1ASRA, and L1AARA, respectively. 

In our example, we are re-using the same JCL start procedure names for 
the Version 7.0 primary node. Clearing the box means the migration utility 
will not replace the START strings held in the configuration XML. 

Because we are re-using the same JCL start procedure names, we 
cleared Replace started procedure command names. 

The Version 7.0 start procedures have a different format that the Version 
6.x start procedures, so the old Version 6.1 .2 procedures need be 
overwritten. Before starting the migrated servers, the *CPY1 job needs to 
be executed to overlay the existing JCL start procedures in your JCL 
procedure library. This step is discussed in 7.3.1 1 , “Start the migrated 
environment” on page 433. 

- When migrating a managed node, the migration utility attempts to make 
contact with the running DMGR, so it will need a user ID and password 
that will allow it access. 

• If global security is off for the cell, then this value is not required for the 
migration, but the MMT requires that the ID field and the password 
fields be populated. You may use the defaults. 

• If security is enabled, provide a valid ID and password to access the 
DMGR. 


Note: The password value is encrypted in the files that are created, 
both in the MMT tool and in the uploaded job files. 


Click Next. 
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10. For the next window, we provided the input shown in Figure 7-48. 



Figure 7-48 Server customization for primary node migration: Part 2 

- The Migrate to support script compatibility check box determines whether 
the migrated configuration will be compatible with the earlier versions of 
the WSADMIN scripting interface. We cleared it because we did not have 
scripts with script compatibility issues. 

- We left all the Migration trace options boxes cleared. Check these boxes 
only when directed to do so by IBM Support. The trace options produce 
significant amounts of output. 

- We use the default Migrating My tasks settings. 
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- The temporary directory location is where the migration utility creates the 
temporary files it needs during the migration run. We create a separate 
directory, /was70config/l lmi grate/temp, which is distinct from the system 
/tmp directory, and we allocated and mounted a file system at that location 
that was 1 .5 times the current size of the node’s configuration file system. 
We made sure the permissions on this directory were 777. 


Important: 

► Depending on the size of the configuration, the migration utility might 
need up to 500 cylinders of temporary space. Allocate and mount a 
temporary file system of that size and point to that location in this 
field. 

Lack of space is one of the most common causes of migration job 
failure. 

► If you are performing multiple migrations, or you are rerunning a 
migration, remember to clean out the temporary directory so you 
have the maximum space available to you. 
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1 1 .In the window shown in Figure 7-49, you can create the JOB card that will be 
used in the generated jobs. You should update this card to conform with your 
normal procedures. Figure 7-49 shows the JOB card used in our z/OS 
system. 



Figure 7-49 JOB card for the generated jobs 
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12. Figure 7-50 shows the migration summary. Click the Create button to create 
the migration definition. 


Migration Summary 

z/OS migrate a federated node 


The migration definition that yon are creating has the following characteristics: 
Type: 

|z/0S migrate a federated node 


D : \ zOS VZCELLAprofiles VNODE A. 3 



Click Back to change the characteristics of the migration definition: otherwise, 
click Create to create the z/OS migration jobs. 


[ < Back j | Create | Finish [ Cencel j 

Figure 7-50 Migration summary for the primary node 
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13. Finally, the migration definition for the primary node is created successfully 
(Figure 7-51). 



Figure 7-51 Migration definition is created successfully 

Process (upload) the definition to z/OS 

The next step transfers the generated customized jobs that are used to migrate 
the primary node from the MMT tool on your workstation on to the z/OS system 
where they will be run. 

Perform the following steps: 

1 . Select the NODEA definition we just created and click the Process button. 
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2. Select the option to upload to z/OS (Figure 7-52). 



Figure 7-52 Select upload option 
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the upload to z/OS to 


(Figure 7-53). 



Figure 7-53 Provide parameters for upload jobs 


- Provide the host IP name of the system on which the jobs will be run. 

- Provide a user ID and password for the FTP upload. 

- Modify the port if you know your system uses something other than 21 for 
FTP. 
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- Check Allocate target z/OS data sets (leave it clear if you are 
pre-allocating manually). 

- Specify the volume and unit or leave it blank. 

Click Finish. 

4. Watch the progress bar (Figure 7-54). 



Figure 7-54 The progress bar 

5. The “Upload successful” message will be displayed (Figure 7-55). 



Figure 7-55 Upload successful 
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6. You should see the MMT main window again. The customized migration jobs 
for the primary node on the z/OS system are ready to be submitted. We 
validate that the data sets have been created and that they contain the 
expected member. The CNTL data set looks like the panel shown in 
Figure 7-56. 


VIEW WPSCFG . MIGNODEA . CNTL 

Command ===> 

Name Prompt Size 

BBOMMAJ 

BBOMMCP 

BBOMMCR 

BBOMMDN 

BBOMMHFS 

BBOMMINS 

BBOMMSR 

BBOMMZFS 

BBOSCHED 

BBOWMG1F 

BB0WMG2F 

BB0WMG3F 

BBOWMPOS 

BBOWMPRE 

BBOWMPRO 

**End** 


Figure 7-56 The data sets contained the generated migration jobs 

Edit and submit the WebSphere Process Server migration jobs 

After the WebSphere Application Server migration jobs and variables are 
generated and uploaded by the z/OS MMT tool, we can edit the sample 
WebSphere Process Server migration jobs BPZWMG1 F, BPZWMG2F, and 
BPZWMG3F to make use of these WebSphere Application Server migration 
jobs. 

After these jobs are submitted, they invoke the WebSphere Process Server script 
wbimigrt2.sh, which is very similar to the WebSphere Application Server script 
bbomigrt2.sh. The wbimgrt2.sh script invokes the migration utilities 
BPMSnapshotSourceProfile.sh and BPMMigrateProfile.sh to migrate the 
WebSphere Process Server V6.1 .2 primary node to Version 7.0. 
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Perform the following steps: 

1 . Find the sample WebSphere Process Server migration jobs BPZWMG1 F, 
BPZWMG2F, and BPZWMG3F in the installed WebSphere Process Server 
JCL PDS (.**.SBPZJCL). In our z/OS system, the JCL PDS is located in 
BBL27061 .SBPZJCL PDS. Copy these three jobs to your working PDS and 
change their names to BPZWMG1 A, BPZWMG2A, and BPZWMG3A, 
respectively. In this sample, we use WPSCFG.WPS.JCL as the working PDS. 


VIEW WPSCFG.WPS.JCL 

Command ===> 

Name Prompt 

| BPZWMG in | 


| BPZWMG2A | 

BPZWMG2B 

| BPZWMG3A | 

BPZWMG3B 

BPZWMG3D 

L lflDMI NS 

L1DMSYM 

L1EJB 

L1GEJB 

L1H0MEG 

L1NASYM 

L1NBSYM 


Figure 7-57 Migration jobs to migrate the primary node 

2. Edit BPZWMG1 A, BPZWMG2A, and BPZWMG3A so that you can use the 
WebSphere Application Server migration jobs generated by MMT: 
a. Add a JOB card for BPZWMG1 A, BPZWMG2A, and BPZWMG3A to make 
sure that you use the administrator user name and password. 

Example 7-10 shows the JOB card for the BPZWMGlAjob used in our 
environment. For the BPZWMG2A and BPZWMG3A jobs, add JOB card in 
the same way. 

Example 7-10 JOB card for the BPZWMG 1A job 


//BPZWMG1F JOB NOTIFY=&SYSUID,CLASS=A,MSGCLASS=H, 
// REGI0N=0M,TIME=1440, 

// USER=L1ADMIN, PASSW0RD=L1ADMIN 

/*J0BPARM S=SC61 

//* 
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b. Replace the following parameters in BPZWMG1 A, BPZWMG2A, and 
BPZWMG3A according to the primary node configuration and the 
parameters entered in MMT. Example 7-1 1 shows the parameters for the 
primary node in our z/OS system. 


Example 7-11 Replace parameters in BPZWMG1A, BPZWMG2A, and BPZWMG3A jobs 


//* 

Itempdi r# 

temporary working directory 

* 

//* 


eg. V7 .OOfnl 

* 

//* 


V7.00N0DEA 

* 

//* 



* 

//* 

Iwpsndi r# 

directory of the V7.0.0 WPS product 

* 

//* 


eg. /usr/1 pp/zWPS/V7.0R0 

* 

//* 


/usr/lpp/zWPSL2/V7.0R0 

* 

//* 



* 

//* 

Iwpsosvr# 

home directory of the old wps server 

* 

//* 


eg. /WebSphere/V62FNl 

* 

//* 


/was61conf i g/1 lcel 1 /I lnodea 

* 

//* 



* 

//* 

Iwpsnsvr# 

home directory of the new wps server 

* 

//* 


eg. /WebSphere/V7 .00FN1 

* 

//* 


/was70conf i g/1 lcel 1 /I lnodea 

* 

//* 



* 

//* 

Iwassmpe# 

dir of the WAS smpe install 

* 

//* 


eg . /usr/1 pp/zWebSphere/V7 . 00P4098 

* 

//* 


/usr/1 pp/zWebSphereL2/V7 . 0R0 

* 

//* 



* 

//* 

Iprocdmn# 

name of the started task procedure (daemon) 

* 

//* 


eg WDFN1Z1 

* 

//* 


L1DEMNA 

* 

//* 



* 

//* 

#procctr# 

name of the started task procedure (control) 

* 

//* 


eg WCFN1Z1 

* 

//* 


L1ACRA 

* 

//* 



* 

//* 

#procadj# 

name of the started task procedure (adjunct) 

* 

//* 


eg WAFN1Z1 

* 

//* 


L1AARA 

* 

//* 



* 

//* 

#procsvr# 

name of the started task procedure (servant) 

* 

//* 


eg WSFN1Z1 

* 

//* 


L1ASRA 

* 

//* 



* 

//* 

Imigrpds# 

hlq of pds of migration jobs created by WebSphere 

* 

//* 


Customisation panels. 

* 
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//* 


eg. ZWPS . WAS . V7 . 00 . V7 . 00FN1 

.MIG 


//* 


WPSCFG.MIGNODEA 


* 

//* 




* 

//* 

Itouserid# 

if security is switched on 

in the old wps server 

* 

//* 


then supply the userid. 


* 

//* 


eg. wsadmin 


* 

//* 


lladmin 


* 

//* 




* 

//* 

Itopswd# 

if security is switched on 

in the old wps server 

* 

//* 


then supply the password. 


* 

//* 


lladmin 


* 


3. Next, you need to submit BPZWMG1 A, BPZWMG2A, and BPZWMG3A. If 
there were XA connectors installed in the Version 6.1 .2 server, the 
BPZWMG1A and BPZWMG2A jobs need to be run. Otherwise, only submit 
the BPZWMG3A job to do the actual migration. In our example, we need to 
execute all three jobs, because XA connectors are used in the Version 6.1 .2 
source environment. 

4. Execute the BPZWMG1 A job: 

a. Locate the BPZWMG1 A job that you edited in the WPSCFG.WPS.JCL 
PDS (Figure 7-58). 


VIEW WPSCFG.WPS. JCL(BPZWMGIFI) - 01.00 Columns 00001 00072 

Command ===> submit_ Scroll ===> PAGE 

****** ***************************** Top of Data ***************************** 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BPZWMG1F JOB NOTIFY=&SYSUID,CLflSS=fl,MSGCLflSS=H, 

000002 // REGION=0M,TIME=1440, 

000003 // USER=LlflDMIN,PRSSWORD=LlfiDMIN 
000004 /*J0BPflRM S=SC61 
000005 //* 

000006 //********************************************************************* 
000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp . 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclos 
000011 //* restricted by GSfl fiDP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive 
000013 //* of its trade secrets, irrespective of what has been deposited with 
000014 //* U.S. Copyright Office. 

Figure 7-58 The BPZWMG1A job 
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b. Submit the modified BPZWMG1A job (Figure 7-59). 


VIEW WPSCFG.WPS. JCL(BPZWMGlfl) - 01.00 Columns 00001 00072 

Command ===> submit Scroll ===> PAGE 

****** ***************************** Top of Data *****************************: 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 / /BPZWMG1F JOB N0TIFY=8.SYSUID , CLfiSS=n , MSGCLASS=H , 

000002 // REGION=0M,TIME=1440, 

000003 // USER=LlflDMIN,PflSSWORD=LlRDMIN 
000004 /*J0BPRRM S=SC61 
000005 //* 

000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp . 2007, 2O09 
000010 //* US Government Users Restricted Rights - Use, duplication or disclosi 
000011 //* restricted by GSH flDP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive; 
000013 //* of its trade secrets, irrespective of what has been deposited with 
JOB BPZWMG1F(J0B24453) SUBMITTED 


Figure 7-59 Submit the BPZWMG1A job 

c. Examine the output in /tmp/migrate/#tempdir#/BPZWMGlF.out to make 
sure that the BPZWMG1A job completed successfully. The #tempdir# is 
the parameter you defined as V7.00NODEA (see Example 7-1 1 on 
page 406). The output is shown in Example 7-12 as BPZWMGIF.out. 

Example 7- 12 Output in BPZWMGIF.out 
STEP: MKCONFIG 


BB0J0054I Transformer symlink - Already Linked: 

/was61config/l lcel 1 /I Inodea/LICELL. L1N0DEA. L1CL011 -> 

/was61conf ig/1 lcel 1 /l Inodea/AppServer/prof i 1 es/defaul t/conf i g/cel 
1 s/1 lcel 1 /nodes/1 lnodea/servers/1 lclOll 
BB0J0054I Transformer symlink - Already Linked: 

/was61config/l lcel 1/1 Inodea/LICELL. L1N0DEA . L1CL01 1 . HOME -> 
/was61config/l lcel 1 /l Inodea/AppServer 
BB0J0056I Transformer Processing Complete, RC=0. 
preMi grate completed... 
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5. Execute the BPZWMG2A job: 

a. Locate the BPZWMG2A job that you edited in the working 
WPSCFG.WPS.JCL PDS (Figure 7-60). 


VIEW WPSCFG.WPS. JCL(BPZWMG2A) - 01.00 Columns 00001 00072 

Command ===> submit_ Scroll == = > PAGE 

****** ***************************** Top of Data ***************************** 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BPZWMG2F JOB N0TIFY=&SYSUID , CLASS=A , MSGCLASS=H , 

000002 // REGION=0M,TIME=1440, 

000003 // USER=L1ADMIN,PASSW0RD=L1ADMIN 
000004 /*J0BPARM S=SC61 
000005 //* 

000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp . 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclos 
000011 //* restricted by GSA ADP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive 
000013 //* of its trade secrets, irrespective of what has been deposited with 
000014 //* U.S. Copyright Office. 

000015 //********************************************************************* 

Figure 7-60 The BPZWMG2A job 


b. Submit the modified BPZWMG2A job (Figure 7-61 ). 


VIEW WPSCFG.WPS. JCL(BPZWMG2A) - 01.00 Columns 00001 00072 

Command ===> submit Scroll ===> PAGE 

==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BPZWMG2F JOB N0TIFY=&SYSUID , CLASS=A , MSGCLASS=H , 

000002 // REGION=0M,TIME=1440, 

000003 // USER=L1ADMIN,PASSW0RD=L1ADMIN 
000004 /*J0BPARM S=SC61 
000005 //* 

000006 //*********************************************************************: 
000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp. 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclosi 
000011 //* restricted by GSA ADP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive! 
000013 //* of its trade secrets, irrespective of what has been deposited with 
JOB BPZWMG2F(J0B24465) SUBMITTED 


Figure 7-61 Submit the BPZWMG2A job 
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c. Examine the output in /tmp/migrate/#tempdir#/BPZWMG2F. out to make 
sure the BPZWMG2A job completed successfully. The #tempdir# is the 
parameter you have defined in step 2b on page 406 as V7.00NODEA. You 
can find the output (Example 7-13) in BPZWMG2F.out. 

Example 7-13 Output in BPZWMGIF.out 
STEP: MKCONFIG 


BB0J0054I Transformer symlink - Already Linked: 

/was61config/l lcel 1 /I Inodea/LICELL. L1N0DEA. L1CL011 -> 

/was61conf ig/1 lcel 1 /l Inodea/AppServer/prof i 1 es/defaul t/conf i g/cel 
1 s/1 lcel 1 /nodes/1 lnodea/servers/1 lclOll 
BB0J0054I Transformer symlink - Already Linked: 

/was61config/l lcel 1/1 Inodea/LICELL. L1N0DEA . L1CL01 1 . HOME -> 
/was61config/l lcel 1 /l Inodea/AppServer 
BB0J0056I Transformer Processing Complete, RC=0. 
postMi grate completed... 


6. Execute the BPZWMG3A job: 

- Locate the BPZWMG3A job that you edited in the WPSCFG.WPS.JCL 
PDS (Figure 7-62). 


VIEW WPSCFG.WPS. JCL(BPZWMG3fl) - 01.00 Columns 00001 00072 

Command ===> submit_ Scroll ===> PAGE 

****** ***************************** Top of Data *****************************> 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 / /BPZWMG3F JOB N0TIFY=&SYSUID , CLfiSS=fi , MSGCLASS=H , 

000002 // REGION=0M,TIME=1440, 

000003 // USER=LlADMIN,PflSSWORD=LlflDMIN 
000004 /*J0BPARM S=SC61 
000005 //* 

000006 //*********************************************************************> 
000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp . 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclosi 
000011 //* restricted by GSH RDP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dive; 
000013 //* of its trade secrets, irrespective of what has been deposited with 1 
000014 //* U.S. Copyright Office. 

Figure 7-62 The BPZWMG3A job 
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Submit the BPZWMG3A job (Figure 7-63). 


VIEW WPSCFG.WPS. JCL(BPZWMG3fl) - 01.00 Columns 00001 00072 

Command ===> submit Scroll ===> PAGE 

****** ***************************** Top of Data ****************************** 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BPZWMG3F JOB NOTIFY=&SYSUID , CLASS=fi , MSGCLfiSS=H, 

000002 // REGION=0M,TIME=1440, 

000003 // USER=L1 ADMIN,PFISSWORD=LlflDMIN 
000004 /*J0BPflRM S=SC61 
000005 //* 

000007 //* Licensed Materials - Property of IBM 
000008 //* 5655-W05 

000009 //* (C) COPYRIGHT International Business Machines Corp . 2007, 2009 
000010 //* US Government Users Restricted Rights - Use, duplication or disclosu 
000011 //* restricted by GSfl flDP Schedule Contract with IBM Corp. 

000012 //* The source code for this program is not published or otherwise dives 
000013 //* of its trade secrets, irrespective of what has been deposited with 
JOB BPZWMG3F(JOB24470) SUBMITTED 


Figure 7-63 Submit the BPZWMG3A job 


After the BPZWMG3A job is submitted, it executes the WebSphere Process 
Server script wbimigrt2.sh, which is very similar to the WebSphere 
Application Server script bbomigrt2.sh. The wbimgrt2.sh script invokes the 
migration utilities BPMSnapshotSourceProfile.sh and BPMMigrateProfile.sh 
to do the actual migration. The migration of a source profile consists of two 
steps in the following sequence: 

a. Take a backup of the source profile to the snapshot directory. The 

BPMSnapshotSourceProf i 1 e . sh command is executed to take the snapshot 
of the source profile. The snapshot directory is /tmp/migrate/V7.00N0DEA 
(Figure 7-64). 



Figure 7-64 The snapshot directory 
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b. Migrate the source profile to the target profile. The BPMMi grateProf i 1 e . sh 
command is executed to migrate the source profile. 

7. Examine the output in /tmp/migrate/#fempc/ir#/BPZWMG3F.out and 
/tmp/migrate/#£empdir#/fed_backup/logs to make sure the migration 
completed successfully. The #tempdir# parameter in this case is 
V7.00NODEA (Example 7-1 1 on page 406). 


S ^ Si T fijt X | |i/migrate/v70NQDEA/fed_backup/logs 1 1 Add 
Remote Name 

0 BPMMi grateProfile. default. Mon-Apr-19-13. 52. 01-EBT-2010. log 
0 BFMFrofileUp grade. default. Mon-Apr-19-14. 00. 42-2010. log 
§§BPMProfileUpgrade. default. Mon-Apr-19-14. 00. 42-2010. trace 
0 BPMSnap sho tS our ceProfile. default. Mon-Apr- 19-1 3. 44. 04-EBT-2010. log 
0 syncNode. Mon-Apr-19-14. 04. 19-EDT-2010. log 
§§WASPostVpgrade. default. Mon-Apr-19-13. 52. 02-EDT-2010. trace 
0 WASP o s tUp gr ade . default. Mon-Apr-19-13. 52. 09-2010. log 
gWASPreUpgrade. default. Mon-Apr-19-13. 44. 08-EDT-2010. trace 
0 WASPreUp grade. Mon-Apr-19-13. 44. 16-2010. log 

Figure 7-65 Logs created for the primary node migration 

a. Step 6a on page 41 1 creates the following log files in the 1 ogs 

subdirectory of the snapshot/fed_backup directory. You can examine these 
logs to monitor the progress of the snapshot activity. The 1 og . 1 ck file is a 
lock file, which indicates an instance of an activity is taking a snapshot of 
the primary node profile that is already running. This is a mechanism that 
is used to prevent multiple snapshot activities by different users. 

^ 3 fi Qi |/tmp/migrate/v70NODEA/fed_backup/logs Add 

Remote Name > Size 

0 BFMSnapshotSourceFrofile. default. Mon-Apr-19-13. 44. 04-EDT-2010. log 10, 597 

0 BFMSnapshotSourceFrofile. default. Mon-Apr- 19- 13. 44. 04-EDT-2010. log. lck 0 

g WASPreUp grade, default. Mon-Apr-1 9- 13. 44. 08-EBT-2010. trace 2, 882 

0 WASPreUpgrade. Mon- Apr-19-13. 44. 16-2010. log 330 

Figure 7-66 Logs created for snapshot activity 

After Step 6a on page 41 1 completes, you should see an output similar to 
Example 7-14 in BPMSnapshotSourceProfile.default.rime_Sfamp.log. 

Example 7- 1 4 Output for snapshot activity 

[4/19/10 1:51:44 PM EDT] 0 BPMSnapshotNode F invokeAdditionalMigr 
Serial i zing file = 

[/SC61/tmp/mi grate/V7 .OONODEA/fed_backup/prof i 1 es/defaul t/defaul t 
.prof info] 
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[4/19/10 1:51:44 PM EDT] 0 Fi 1 ellti 1 i ties > serial izeObject 
ENTRY 

{/SC61/tmp/migrate/V7.00N0DEA/fed_backup/profi les/default/defaul t 
.prof info} 

[4/19/10 1:51:44 PM EDT] 0 Fi 1 ellti 1 i ties < serial izeObject 
RETURN 

[4/19/10 1:51:44 PM EDT] 0 BPMSnapshotNode < invokeAdditionalMigr 
RETURN 

[4/19/10 1:51:44 PM EDT] 0 WBIUpgradeBase < migrate 
RETURN 

[4/19/10 1:51:45 PM EDT] 0 BPMSnapshotNode I main(String[] args) 
CWMC00823I : The BPMSnapshotSourceProfi le command finished 
successful ly. 


b. In step 6b on page 41 2, the actual migration of the data from the snapshot 
directory to the target profile is performed. During this step, the migration 
process performs the following actions: 

• Changes the local properties. 

• Connects to the deployment manager and changes the node 
information on the master repository. 

• Installs new system applications if required. 

The logs for this step are also created in the 1 ogs subdirectory of the 
snapshot/fed_backup directory. Check for any errors in these log files: 

• BPMMi grateProf i 1 e . def aul t . T ime_Stamp . 1 og 

• BPMProf i 1 eUpgrade. def aul t .Time_Stamp . 1 og 

• BPMProf i 1 eUpgrade . def aul t . T ime_Stamp .trace 

• WASPostUpgrade . def aul t . T ime_Stamp . trace 

• WASPostUpgrade . def aul t . T ime_Stamp . 1 og 
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c. The BPZWMG3A job synchronizes the target primary managed profile 
with the running deployment manager. The changes made at the 
deployment manager (master repository) will be synchronized to the local 
repository. The synchronization step also creates a log file in the 1 ogs 
subdirectory, as shown in Figure 7-67. 


Cji Im! T 2j< |)/migrate/v70NODEA/fed_backup/logs ▼] Add 
Remote Name 

© BPMMi grateProf ile. default. Mon-Apr- 19- 13. 52. 01-EDT-2010. log 
© BPMProfilelJp grade, default. Hon- Apr-19-14. 00. 42-2010. log 
gBFHFrofileUpgrade. default. Mon-Apr-19-14. 00. 42-2010. trace 
©^PMSnagsholSourceProfile^defaultJloi^^r^lS-lS. 44. 04-EDT-2010. log 
111 ) syncHode. Mon-Apr-19-14. 04. 19-EDT-2010. log | 

[Eg] WASPostUp grade, default. Mon-Apr- 19- 13. 52. 02-EDT-2010. trace 
© WASPostUp grade, default. Mon-Apr- 19- 13. 52. 09-2010. log 
gWASFreUpgrade. default. Mon-Apr- 19- 13. 44. 08-EDT-2010. trace 
© WASFreUpgrade. Mon- Apr-19-13. 44. 16-2010. log 

Figure 7-67 The syncNode log file 

d. After both steps have completed successfully, check the output in 
/tmp/migrate/#tempdir#/BPZWMG3F.out. You can find the output in 
Example 7-15 as BPZWMG3F.out. 

Example 7-15 Output in BPZWMG3F.out 


STEP: MKCONFIG 


CWMC00224I : The WebSphere Application Server utility has 
completed. 

CWMC00208I : See the following log file for information: 
/SC61/tmp/migrate/V7.00N0DEA/fed_backup/logs/WASPrellpgrade.<TIMES 
TAM P>. log 

CWMC00823I : The BPMSnapshotSourceProfile command finished 
successful ly. 

CWMC00224I : The WebSphere Application Server utility has 
completed. 

CWMC00208I : See the following log file for information: 
/SC61/tmp/mi grate/V7.00N0DEA/fed_backup/logs/syncNode. Mon-Apr-19- 
14. 04. 19-EDT-2010.log 

CWMC00822I : The BPMMigrateProfi 1 e command finished successfully. 
CWMC00850I: See the migration documentation for additional 
migration tasks that are specific to your configuration such as 
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upgrading database schemas and/or running BPMMigrateCl uster 
command for clusters. 

Migration Completed Successfully... 


7.3.6 Migrating the secondary node 

Here we give the steps to perform the migration on the secondary node. These 
steps are similar to the ones performed during the migration of the primary node 
in 7.3.5, “Migrating the primary node” on page 387. We will only mention the 
steps where there are differences. 

Perform the following steps: 

1 . Make sure that the deployment manager in the target environment is running 
and the node agent is stopped. 

2. Create a migration definition, NODEB, for the secondary node in MMT: 
a. Provide the high-level qualifier for z/OS data sets of 

WPSCFG.MIGNODEB that will hold the generated jobs for the secondary 
node from MMT (Figure 7-68). 
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We used the high-level qualifier WPSCFG.MIGNODEB, which results in 
the following data sets being used: 

• WPSCFG.MIGDNODEB.CNTL 

• WPSCFG.MIGNODEB. DATA 

b. Provide the mount point, the data set name, and the volume name for the 
Version 7.0 secondary node’s configuration file system (Figure 7-69). 



Figure 7-69 File system configuration for the Version 7.0 secondary node 
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c. Provide the migration information for the secondary node, including the 
secondary node’s “from” and “to” mount point, and the JCL start procedure 
names for the secondary node, including the daemon, controller, servant, 
and adjunct procedures (Figure 7-70). 



Figure 7-70 Server customization for secondary node migration 
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3. Upload the migration jobs for the secondary node to z/OS (Figure 7-71). 



Figure 7-71 Upload the migration jobs for the secondary node to z/OS 


4. After the customized migration jobs for the secondary node are on the z/OS 
system, we validate that the data sets have been created and that they 
contain the expected member. 
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Figure 7-72 shows the CNTL data set. 


VIEW WPSCFG . MIGNODEB . CNTL 

Command ===> 

Name Prompt Size 

BBOMMAJ 

BBOMMCP 

BBOMMCR 

BBOMMDN 

BBOMMHFS 

BBOMMINS 

BBOMMSR 

BBOMMZFS 

BBOSCHED 

BBOWMG1F 

BB0WMG2F 

BB0WMG3F 

BBOWMPOS 

BBOWMPRE 

BBOWMPRO 

**End** 


Figure 7-72 The data sets containing the generated migration jobs 


5. Edit the WebSphere Process Server migration jobs: 

a. Copy the sample migration jobs BPZWMG1 F, BPZWMG2F, and 

BPZWMG3F to the working PDS and change their names to BPZWMG1 B, 
BPZWMG2B, and BPZWMG3B, respectively. In our example, we used the 
WPSCFG.WPS.JCL PDS. 


VIEW WPSCFG.WPS.JCL 

Command = = => 

Name Prompt 

BPZWMGlfl 

IbpzwmgibI 

BPZWMG2B 

IBPZWMG2B1 

BPZWMG3B 

|BPZWMG3Bl 

BPZWMG3D 

L1ADMINS 

L1DMSYM 

L1EJB 

L1GEJB 


Figure 7-73 Migration jobs to migrate the secondary node 

b. Edit the BPZWMG1 B, BPZWMG2B, and BPZWMG3B jobs. 

Add a JOB card for BPZWMG1 A, BPZWMG2A, and BPZWMG3A. 
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Replace the following parameters in BPZWMG1B, BPZWMG2B, and 
BPZWMG3B according to the secondary node configuration, and the 
parameters entered in MMT. Example 7-16 shows the parameters for the 
secondary node in our z/OS system. 


Example 7-16 Parameters replaced in BPZWMG1B, BPZWMG2B, and BPZWMG3B 


//* 

Itempdi r# 

temporary working directory 

* 

//* 


eg. V7 .OOfnl 


//* 


V7.00N0DEB 


//* 



* 

//* 

Iwpsndir# 

directory of the V7.0.0 WPS product 


//* 


eg. /usr/1 pp/zWPS/V7.0R0 


//* 


/usr/lpp/zWPSL2/V7.0R0 


//* 



* 

//* 

Iwpsosvr# 

home directory of the old wps server 

* 

//* 


eg. /WebSphere/V62FNl 

* 

//* 


/was61conf i g/1 lcel 1 /I lnodeb 

* 

//* 



* 

//* 

#wpsnsvr# 

home directory of the new wps server 

* 

//* 


eg. /WebSphere/V7 .00FN1 


//* 


/was70config//l lcel 1 /I lnodeb 

* 

//* 



* 

//* 

Iwassmpe# 

dir of the WAS smpe install 

* 

//* 


eg . /usr/1 pp/zWebSphere/V7 . 00P4098 


//* 


/usr/1 pp/zWebSphereL2/V7 . 0R0 


//* 



* 

//* 

Iprocdmn# 

name of the started task procedure (daemon) 

* 

//* 


eg WDFN1Z1 

* 

//* 


L1DEMNB 

* 

//* 



* 

//* 

#procctr# 

name of the started task procedure (control) 

* 

//* 


eg WCFN1Z1 

* 

//* 


L1ACRB 

* 

//* 



* 

//* 

Iprocadj# 

name of the started task procedure (adjunct) 

* 

//* 


eg WAFN1Z1 

* 
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L1AARB 


//* 

//* 

//* 

//* 

//* 

//* 

//* 

//* 

//* 


fprocsvr# name of the started task procedure (servant) * 

eg WSFN1Z1 * 

L1ASRB * 

#migrpds# hlq of pds of migration jobs created by WebSphere * 

Customisation panels. * 

eg. ZWPS.WAS. V7 .00.V7 .00FN1 .MIG 


//* WPSCFG.MIGNODEB * 

//* 

II* ftouserid# if security is switched on in the old wps server * 
//* then supply the userid. * 

//* eg. wsadmin * 

//* lladmin * 

II* 

II* ftopswd# if security is switched on in the old wps server * 
//* then supply the password. * 

//* lladmin * 


6. Submit the edited jobs BPZWMG1 B, BPZWMG2B, and BPZWMG3B. 

As was the case when migrating the primary managed profile, these jobs 
perform the migration on the secondary node. 

The jobs create corresponding logs in each step of the migration. Examine 
the output in /tmp/migrate/#tempc/ir#/BPZWMGxF.out and 
/tmp/migrate/#tempc/ir#/fed_backup/logs to make sure the migration 
completed successfully. The #tempdir# is V7.00NODEB. 


7.3.7 Migrating the cluster 

After the managed nodes are migrated, all clusters in the source environment 
must be migrated. The cluster migration is done by using the BPMMigrateCluster 
script. 

Example 7-17 shows the usage information of the BPMMigrateCluster script. 

Example 7- 1 7 Usage information of the BPMMigrateCluster script 

Usage: BPMMigrateCluster <backupDir> <cluster> <target deployment 
manager profile name> 
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► <backupDir> is the migration snapshot directory that contains the backup 
configuration of the source deployment manager. It is 
/tmp/migrate/#fempcfir# on z/OS. The fftempdir# parameter is the one you 
had defined in the WebSphere Process Server migration job BPZWMG3D for 
the deployment manager in “Edit and submit the migration job BPZWMG3D” 
on page 374. 

► <cluster> is the cluster name that will be migrated. 

The BPMMigrateCluster script should be executed from the target deployment 
manager bi n directory. 

Perform the following steps to migrate the cluster: 

1. Log on to z/OS via telnet or ssh. 

2. Change the working directory to the target deployment manager bi n directory. 
On our z/OS system, it is 

/was70config/l lcel 1 /I ldmnode/DeploymentManager/bin. 

3. There is only one cluster in the source environment on z/OS, so we execute 
the BPMMigrateCluster script once: 

./BPMMigrateCl uster. sh /tmp/migrate/V7.00DMGR llclOl default 

4. The BPMMigrateCluster.sh generated log files are under <backupDi r>/l ogs. 
The log file names are: 

- BPMMigrateCl uster . <Dmgr Name>.<Time Stamp >. log 

- BPMMigrateCl uster . <Dmgr Name> . <Time Stamp >. trace 
Examine the output to make sure that the cluster migration process 
completed successfully. 


■a 3 sa * 

Qjf X nigrate/v70DMGR/dmgr_backup/logs | Add 

Remote Name 

|0 BPMMigrateCluster. default. Mon-Apr-19- 

-14. 59. 26-2010. log 

0;BPMMigrateClus' 

ter. default. Mon-Apr-19- 

-14. 59. 26-2010. trace 1 | 

T) BPMMi grateProf: 

ile. default. Fri-Apr-16- 

■14. 11.06-EDT-2010. log 

0 BPMProfilellp grade. default. Fri-Apr-16- 

■14. 30. 48-2010. log 

g BPMPr ofileUpgrade. default. Fri-Apr-16- 

-14. 30. 48-2010. trace 

0 BPMSnap shot Soul 

rceProfile. default. Fri- 

■ Apr-16-14. 02. 2T-EBT-2010. log 

Bi WASP ostUp grade 

default. Fri-Apr-16-14. 

11. 06-EDT-2010. trace 

0 WASP ostUp grade 

default. Fri-Apr-16-14. 

11.14-2010. log 

gWASPreUp grade. , 

default. Fri-Apr-16-14. C 

)2. 30-EDT-2010. trace 

0 WASPreUpgrade. 1 

Pri-Apr-16-14. 02. 38-2010. log 


Figure 7-74 Generated log files for the BPMMigrateCluster.sh script 
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7.3.8 Synchronizing the nodes 


STOP: Back up the file system of the target WebSphere Process Server V7.0 
installation. This backup is needed in case the syncNode command fails. 

If the synchronization procedure fails, you need restore the backup and redo 
the synchronization. Refer to the Technote found at the following address: 

http : //www. ibm.com/support/docview.wss?uid=swg2 1410474 


After cluster migration, all managed nodes need be synchronized with the 
running target deployment manager. This is done by executing the syncNode 
script from each managed node bin directory. 

If, before running the synchronization, you check the installed applications under 
the <1/7. 0_CUST0M_PR0FILE_R00T>/ \ nstal 1 edApps /<££££ JV/W£> directory, you will 
see that some applications (Failed Event Manager, Remote AL and BPC 
Container, and so on) are still at Version 6.1 .2, so this synchronization step is 
mandatory. 

Figure 7-75 shows the installed applications in 

/was70conf ig/1 lcel 1 /l Inodea/AppServer/prof i 1 es/defaul t/instal 1 edApps/1 1 
cel 1 in our environment before synchronization. 


tfi tjJ S 7’ G# |nfig/l lcell/l Inodea/AppServer/ proflles/default/installedApps/l lcell | Add 

Remote Name 

Size TvDe 

Modified 

Attributes 

£>psFEMgr_6.1.2.ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

QTaskContainer _11 clOl . ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

Qsca. sib. mediation, ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

|g|KemoteAlJ61. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

If^lpersi stentUkMer. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

£2|ITS0_vlApp. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

QITS0_med_vlApp. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

|g|ITSO_impl_vlApp. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

£□ HTM_Pr edefinedTasks_V612_llcl01. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

|^|KrM_Prede£inedTasHlsg_V612_llcl01. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

IC3)EventService. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

PftDefanltAppli cation, ear. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

If^lBusines sRul e sM anager . ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

S|BPEContainer_llcl01. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

£jBPCExplorer_llcl01. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx 

PfrApnSchednler. ear 

Folder 

2010-04-19 12 

5. . . drwxrwx— 


Figure 7-75 Applications in the primary node before synchronization 
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For the TaskContainer and BPEContainer application, their version can be 
determined from MANIFEST.MF of the EAR file. Example 7-1 8 shows the 
MANIFEST.MF content of TaskContainerJ lclOl.ear before synchronization. 

Example 7-18 MANIFEST.MF of TaskContainerJ 1 clOI .ear before synchronization 

Manifest-Version: 1.0 
Ant-Version: Apache Ant 1.6.5 
Specification-Vendor: IBM Corp. 

Implementation-Vendor: IBM Corp. 

Created-By: 2.3 (IBM Corporation) 

Implementation-Title: task. ear 

Implementation-Version: 6. 1.2. 3 WBI612.BPCSRVR [o0924.02] 

Specification-Title: task. ear 
Specification-Version: 6.0 


From the primary node bin directory, execute the syncNode script, as shown in 
Figure 7-76. 


XIEZHIQ 8 SC61:/was70config/llcell/llnodea/AppServer/bin>. /syncNode. sh wtsc61.itso.ibm.com 9002 
ADMU0116I: Tool information is being logged in file 

/was70config/llcell/llnodea/AppServer/profiles/default/logs/syncNode. log 

*** SSL SIGNER EXCHANGE PROMPT *** 

SSL signer from target host 9.12.4.32 is not found in trust store safkeyring: ///WASKeyring. L1CELL. 
Here is the signer information (verify the digest value matches what is displayed at the server): 

Subject DN: CN=wtsc61. itso.ibm.com, 0U=L1CELL, 0=IBM 

Issuer DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Serial number: 2 

Expires: Hon Dec 31 22:59:59 EST 2018 

SHA-1 Digest: 2A:54:5A:90:AD:D0:3C:5D:F0:96:B3:8E:2C:18:67:FF:A4:00:2C:E4 

HD5 Digest: 8B: 33: 14: 63: 5A: C7:B2: 16: 8F:D4: 7F: 5F: F8: F2: 42: 7D 

Subject DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Issuer DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Serial number: 0 

Expires: Hon Dec 31 22:59:59 EST 2018 

SHA-1 Digest: 2A:54:5A:90:AD:D0:3C:5D:F0:96:B3:8E:2C:18:67:FF:A4:00:2C:E4 

HD5 Digest: 8B: 33: 14: 63: 5A: C7:B2: 16: 8F:D4: 7F: 5F: F8: F2: 42: 7D 

Add signer to the trust store now? (y/n) y 
Realm/Cell Name: <default> 

Username: lladmin 
Password: 

ADHU0401I: Begin syncNode operation for node llnodea with Deployment Manager 
wtsc61.itso.ibm.com: 9002 

ADMU0016I: Synchronizing configuration between node and cell. 

ADMU0402I: The configuration for node llnodea has been synchronized with 
Deployment Manager wtsc61.itso.ibm.com: 9002 

Figure 7-76 Execute the syncNode script for the primary node 
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From the secondary node bin directory, execute the syncNode script, as shown 
in Figure 7-77. 


XIEZHIQ @ SC61: /was70conf ig/llcell/llnodeb/AppServer/bin>. /syncNode. sh ratsc61.itso.ibm.com 9002 
ADMU0116I: Tool information is being logged in file 

/was70conf ig/llcell/llnodeb/AppServer /prof iles/default/logs/syncNode. log 

*** SSL SIGNER EXCHANGE PROMPT *** 

SSL signer from target host 9.12.4.32 is not found in trust store safkeyring: ///WASKeyring. L1CELL. 
Here is the signer information (verify the digest value matches rahat is displayed at the server) : 

Subject DN: CN=wtsc61. itso. ibm. com, 0U=L1CELL, 0=IBM 

Issuer DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Serial number: 2 

Expires: Mon Dec 31 22:59:59 EST 2018 

SHA-1 Digest: 2A: 54: 5A: 90: AD:D0: 3C: 5D: FO: 96:B3: 8E: 2C: 18: 67: FF: A4: 00: 2C:E4 

MD5 Digest: 8B : 33 : 14: 63 : SA: C7 : B2 : 16 : 8F: D4: 7F: SF: F8 : F2 : 42 : 7D 

Subject DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Issuer DN: CN=WAS CertAuth for Security Domain, 0U=L1CELL 

Serial number: 0 

Expires: Mon Dec 31 22:59:59 EST 2018 

SHA-1 Digest: 2A:54:5A:90:AD:D0:3C:5D:F0:96:B3:8E:2C:18:67:FF:A4:00:2C:E4 

MD5 Digest: 8B: 33: 14: 63: 5A: C7:B2: 16: 8F:D4: 7F: 5F: F8: F2: 42: 7D 

Add signer to the trust store now? (y/n) y 
Realm/Cell Name: <default> 

Username: lladmin 
Password: 

ADMU0401I: Begin syncNode operation for node llnodeb with Deployment Manager 
wtsc61.itso.ibm.com: 9002 

ADMU0016I: Synchronizing configuration between node and cell. 

ADMU0402I: The configuration for node llnodeb has been synchronized with 
D ep 1 oyment Manage r in t.s c61.it s o . ibm . c om : 9 0 0 2 

Figure 7-77 Execute the syncNode script for the secondary node 

The syncNode.sh script generates a log file under <profi le_root>/ 1 ogs called 
syncNode.log. Examine the output to make sure that the syncNode process 
completed successfully. 

Example 7-19 shows the output in 

/was70config/l lcel 1 /l Inodea/AppServer/profi les/defaul t/logs/syncNode.lo 

9 - 

Example 7-19 syncNode. log of the primary node 

************ start Display Current Environment ************ 

[4/19/10 16:26:17:794 EDT] 00000001 AppBi naryProc I BB000222I: 
ADMA7021I: Distribution of application BusinessRulesManager completed 
successful ly. 
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[4/19/10 16:26:17:984 EDT] 00000001 AppBinaryProc I BB000222I: 
ADMA7021I : Distribution of application 
HTM_PredefinedTasks_V7.000_l lclOl completed successfully. 

[4/19/10 16:26:17:993 EDT] 00000001 NodeSyncTask I 

com. ibm.ws. management. sync. NodeSyncTask doSync ADMS0003I: The 

configuration synchronization completed successfully. 

[4/19/10 16:26:17:995 EDT] 00000001 NodeSyncTask A BB000222I: 
ADMS0003I: The configuration synchronization completed successfully. 
[4/19/10 16:26:21:225 EDT] 00000000 AdminTool A BB000222I: 
ADMU0402I: The configuration for node llnodea has been synchronized 
with Deployment Manager wtsc61.itso.ibm.com: 9002 


After synchronization, all applications are at the Version 7.0 level. Figure 7-78 
shows the installed applications on the primary node after synchronization 


tji O T |ell/l lnodea/AppServer/profiles/default/installed Apps/I lcell | , 

Add 

Remote Name . 

Size Type 

Modified 

Attributes 

|^JJwpsFEMgr_7. 0. 0. ear i | 

Folder 

2010-04-19 15:2. 

drwxrw. . 


irTlTaskContainer llclOl. ear 

Folder 

2010-04-19 15:2. 

drwxrw. . 


Q)sca. sib. mediation, ear 

Folder 

2010-04-19 12:5. 

. drwxrw. . 


£PemoteAI£l. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


iglpersistentLkMgr. ear 

Folder 

2010-04-19 15:2. 

drwxrw. . 


Q|ITS0_vlApp. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


j2|ITS0_med_vlApp. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


S|ITSO_impl_vlApp. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


HTH_Pr e de £1 ne dT asks_V700_l 1 . . . 

Folder 

2010-04-19 15:2. 

drwxrw. . 


HTM_Pr edefinedT asks_V6 1 2_1 1 . . . 

Folder 

2010-04-19 12:5. 

drwxrw. . 


|^| HTH_Pr edefinedT askM s g__V700_. . . 

Folder 

2010-04-19 15:2. 

drwxrw. . 


S|KrM_PredefinedTaskMs|_VB12_. . . 

Folder 

2010-04-19 12:5. 

drwxrw. . 


IrTi Events ervi c e . ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


IrTlDefanltAnnli cation, ear. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 


1^ Bus ine s sRul e sM anager_l 1 clOl . . . 

Folder 

2010-04-19 15:2. 

drwxrw. . 


l2)BPEContainer_llel01. ear 

Folder 

2010-04-19 15:2. 

drwxrw. . 


QBPCExplorer_llcl01. ear 

Folder 

2010-04-19 15:2. 

drwxrw. . 


g|AppSchednler. ear 

Folder 

2010-04-19 12:5. 

drwxrw. . 



Figure 7-78 Applications in the primary node after synchronization 


Recheck the TaskContainerJ lclOl. ear version in MANIFEST.MF after 
synchronization (Example 7-20). 

Example 7-20 MANIFEST.MF of TaskContainer_l1cl01.ear after synchronization 

Manifest-Version: 1.0 
DeployVersion: 6. 2. 0.0 
Ant-Version: Apache Ant 1.6.5 
Specification-Vendor: IBM Corp. 

Implementation-Vendor: IBM Corp. 
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Created-By: 2.4 (IBM Corporation) 

Implementation-Title: task. ear 

Implementation-Version: 7. 0.0.1 WBI70.BPCSRVR [of0950.17] 

Specification-Title: task. ear 
Specification-Version: 6.0 


7.3.9 Upgrading the Business Process Choreographer database 

In this section, we upgrade the Business Process Choreographer (BPC) 
database. The source environment uses the BPC database for storing the BPEL 
and human task related data. Before cluster members of the llclOI cluster are 
started, you need to migrate the BPC database. 

This migration can be done manually or by using the Dbdesign generator and 
upgradeDB.sh scripts. In our example, we update it manually by performing the 
following steps: 

1 . Locate the directory that contains the migration upgrade scripts for the BPC 
database. These scripts are generated in database-specific directories within 
the dbscripts directory of the target deployment manager. 
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In this example, the BPC database version we used was DB2 z/OS V9, and 
the directory where the BPC upgrade scripts are located is 
/was70config/l lcel 1 /I ldmnode/wpssmpe/dbscri pts/ProcessChoreographer/ 
DB2zOSV9/ (Figure 7-79). 


| / was70config/l lcell/l ldmnode/ wpssmpe/ dbscripts/ProcessChoreographer/DB2zOSVt y | Add 

Remote Name 

Size 

Modified 


Attributes 

0 createDatabase. sql 

1,212 

2009-12-14 00 

04 

47 -rwxr-xr-x 

0 createDatabase_Observer. sql 

1,270 

2009-12-14 00 

06 

17 -rwxr-xr-x 

0 createFunctionsJava_Observer. sql 

3,569 

2009-12-14 00 

00 

19 -rwxr-xr-x 

0 cr e at eFuzic t i onsSql Observer. sql 

3,529 

2009-12-13 23 

58 

43 -rwxr-xr-x 

0 createS chema. sql 

188, 595 

2009-12-13 23 

56 

47 -rwxr-xr-x 

0 createSchema_Observer. sql 

58, 092 

2009-12-13 23 

51 

26 -rwxr-xr-x 

0 cr eat eT able space, sql 

33, 317 

2009-12-13 23 

52 

42 -rwxr-xr-x 

0 cr eat eT able space Observer, sql 

2,720 

2009-12-13 23 

45 

40 -rwxr-xr-x 

0 dropFuncti ons_0b server, sql 

1,558 

2009-12-13 23 

47 

58 -rwxr-xr-x 

0 dropS chema. sql 

8,263 

2009-12-14 00 

01 

01 -rwxr-xr-x 

0 dropSchema_Observer. sql 

2,587 

2009-12-14 00 

00 

25 -rwxr-xr-x 

0 dr opT able space, sql 

10, 608 

2009-12-13 23 

56 

00 -rwxr-xr-x 

0 dropTablespace_Observer. sql 

1,693 

2009-12-13 23 

50 

07 -rwxr-xr-x 

0 upgr adeS chem a6 02 sql 

83, 867 

2009-12-13 23 

55 

30 -rwxr-xr-x 

0 up gr adeS chem a602DB2 zOS V7 . sql 

81, 978 

2009-12-13 23 

46 

59 -rwxr-xr-x 

0 upgrades chem a610. sql 

78, 472 

2009-12-14 00 

06 

28 -rwxr-xr-x 

0 up gr adeS chem a6 1 0DB2 zOSV7 . sql 

76, 730 

2009-12-14 00 

01 

13 -rwxr-xr-x 

0 up gradeS chem a6 12. sql 

70, 357 

2009-12-14 00 

05 

47 -rwxr-xr-x 

0 up gr adeS chem a6 1 2BB2 zOS V7 . sql 

68, 923 

2009-12-13 23 

56 

33 -rwxr-xr-x 

0 up gradeS chem a620. sql 

65, 869 

2009-12-13 23 

50 

14 -rwxr-xr-x 

0 up gr adeS chem a620BB2 zOSV7 . sql 

64, 285 

2009-12-13 23 

53 

48 -rwxr-xr-x 

0 upgradeTablespace602. sql 

12, 532 

2009-12-13 23 

49 

16 -rwxr-xr-x 

0 upgradeTablespace602BB2z0SV7. sql 

5,921 

2009-12-13 23 

44 

31 -rwxr-xr-x 

0 upgradeTablespace610. sql 

11,283 

2009-12-14 00 

04 

15 -rwxr-xr-x 

0 up gr adeT abl e sp ac e6 1 0DB2 zOSVT . sql 

5,741 

2009-12-14 00 

07 

13 -rwxr-xr-x 

0 upgr adeT ablespace612. sql 

9,889 

2009-12-13 23 

56 

27 -rwxr-xr-x 

0 upgradeTablespace612DB2zOSV7. sql 

4,661 

2009-12-13 23 

58 

26 -rwxr-xr-x 

0 upgr adeT ablespace620. sql 

6, 194 

2009-12-13 23 

47 

26 -rwxr-xr-x 

0 up gr adeT abl e sp ace620DB2 zOSVT . sql 

2,499 

2009-12-14 00 

07 

46 -rwxr-xr-x 


Figure 7-79 The SQL scripts for BPC database 


2. In the directory, look for any SQL files that contain the name upgrade and a 
version number (of the source server) of 612. We found two SQL files in this 
directory that we can use to upgrade the BPC database: 

- upgradeSchema612.sql 

- upgradeTablespace612.sql 
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3. Edit the values in the SQL files to suit your needs. Replace the following 
parameters of the BPC database according to the actual database 
configuration. Example 7-21 shows the parameters we used in our z/OS. All 
the parameters in @*@ have been replaced with the actual values of the BPC 
database configuration. 


Example 7-21 Parameters of BPC database to be replaced 


— @DB NAME@ 

= DB2 Database name 

= L1CELLDB 

— @SCHEMA@ 

= DB2 SQLID (Schema Qualifier) 

= L1CELL 

— 0STOGRP0 

= DB2 Storage group name 

= L1DBST0 

— 0BPTABLE4K0 

= Buffer Pool of 4k Size 

= BP1 

— 0BPTABLE8K0 

= Buffer Pool of 8k Size 

= BP8K0 

— 0BPINDEX0 

= Buffer Pool Index 

= BP2 

— 0BPLOB4K0 

= Buffer Pool Lobs 

= BP3 


4. Save the edited files. Because the DBUtility.sh script will be used to execute 
these SQL files and it uses ASCII input, you do not need to convert the SQL 
files from ASCII to EBCDIC. 

5. Copy the two SQL files to your working directory, for example, 
/u/<username>/Migration/DB/, and assign the appropriate permissions. 

6. Create the corresponding scripts to execute the SQL files. In these scripts, 
the SQL file is executed by running the DBUtility.sh command. 
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The command parameters for DBUtility.sh createTable are shown in 
Figure 7-80. 


"createTable" is the action, following args are needed: 

-DprofilePath=<profilePath> The path of profile 

-DprofileName=<profileName> The name of the profile 

-DdbDelayConf ig=<boolean> The Flag is to be false to create Tables 

-DdbType=<dbtype> The database type 

-DdbName=<dbName> The database name or alias name 

-DsqlScriptPath. default=<defautlSqlPath> 

The default sql script for creating table 
DBUtility will attempt to find sql script for each database type 
in this naming convention <defautlSqlPath>_<dbType>.sql. 

DBUtility will run <defautlSqlPath>, 
if <defautlSqlPath>_<dbType>. sql does not exist. 
-DsqlScriptUame.default=<defautlSqlScriptHame> 

The default sql script for creating table 
DBUtility will attempt to form a sql script path for each database 
in this naming convention <defautlSqlScriptHame>_<dbType>. sql. 
DBUtility will run <defautlSqlScriptHame>, 
if <defautlSqlScriptName>_<dbType>.sql does not exist. 
-DdbHostWame=<dbHostName> The host name or IP address for database server 
-DdbServerPort=<dbServerPort> The JDBC port number for database server 
-D db JDB C C 1 as sp ath=< db JDBC Cl as sp ath> 

The directory path which contains JDBC driver files 
-DdbUserId=<dbUserId> The user id to access database 

-DdbPassword=<dbPassword> The password to access the database 

-Ddblnstance=<dblnstance> The database instance name — only required for Informix 

-DdbSchemaHame=<dbSchemaHame> The schema name 
-DdbConnectionLocation=<dbConnectionLocation> 

The database connection location — only required for zOS 
-D db S to r age Gr oup =< db S to r age Gr oup> 

The database storage group — only required for zOS 
-DdbJDBCProperties=<dbJDBCProperties> 

The directory containing DB2JccConfiguration.properties — only re 

Figure 7-80 The parameters for DBUtility.sh createTable 

The script shown in Example 7-22 was created to execute 
upgradeTablespace612.sql against the BPC database on our z/OS system. 

Example 7-22 Script to execute upgradeTablespace612.sql 
./DBUtility.sh createTable 

-Dprof i 1 ePath=/was70conf i g/1 lcel 1/1 ldmnode/Depl oymentManager/prof i 1 e 
s/default -DprofileName=default -DdbDelayConfig=fal se 
-DdbType=DB2UDB0S390_V9_l -DdbName=DB9K 

-DsqlScriptPath.default=/u/<username>/Migration/DB/upgradeTablespace 
612. sql -DsqlScriptName.defaul t=upgradeTablespace612.sql 
-DdbHostName=wtsc61 . i tso . i bm.com -DdbServerPort=38340 
-DdbJDBCCl asspath=/usr/l pp/db2/db9k/db2910_jdbc/cl asses 
-DdbUserId=peisel -DdbPassword=IBMlq2w -DdbSchemaName=LlCELL 
-DdbConnectionLocation=DB9K -DdbStorageGroup=LlDBSTO 
-DdbJDBCProperti es=/etc/db9k 
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>/u/<username>/Migration/DB/log/output.out 

2»/u/<username>/Migration/DB/log/error.out 


For the script to execute upgradeSchema612.sql, modify the SQL file name 
with the -DsqIScriptPath.default and -DsqIScriptName. default parameters. 

7. Convert the scripts from ASCII to EBCDIC. You can achieve this task by using 
code editing software (such as UltraEdit, Notepad++, and so on) or by the 
using the iconv command to convert the file to EBCDIC, as shown in 
Example 7-23. 

Example 7-23 Using the iconv command 

iconv -t IBM- 1047 -f IS08859-1 Seri pt_upgradeSchema612_CommonDB.sh > 
Script_upgradeSchema612_CommonDB_EBCDIC.sh 


8. Put the scripts into the bi n directory of the target deployment manager profile. 
(/was70conf i g/1 lcel 1 /I ldmnode/Depl oymentManager/bi n in our 
environment). Assign the appropriate permissions to them. 

9. Change the working directory in UNIS System Service to 
/was70config/l lcel 1 /I ldmnode/Depl oymentManager/bi n. Execute the two 
scripts, one at a time. 

10. Check the output of the SQL files in 
/u/<username>/Mi grati on/DB/1 og/output . out and 
/u/<username>/Migration/DB/log/error.out. The output of 
upgradeSchema612.sql in our environment is shown in Example 7-24:. 

Example 7-24 Output for executing upgradeSchema61 2. sql 
BEGIN COPYRIGHT 

execSQLScript: 

[echo] JDBCDriver: com.ibm.db2.jcc.DB2Driver 
[echo] DB_URL: jdbc:db2:DB9K 
[echo] dbUserld: peisel 
[echo] sqlScriptPath: 

/u/pei sel/Mi grati on/DB/upgradeSchema612. sql 
[echo] JDBC_DRIVER_FILE_STATIC: 

/etc/db9k;/usr/l pp/db2/db9k/db2910_jdbc/cl asses/db2jcc. jar;/usr/l pp/ 
db2/db9k/db2910_jdbc/cl asses/db2jcc_l i cense_cu. jar;/usr/l pp/db2/db9k 
/db2910_jdbc/cl asses/db2jcc_l i cense_ci suz . jar 
[echo] common. executeCompl exSQL: false 
[echo] delimiter: ; 

[echo] del imitertype: normal 

[echo] keepformat: false 

[echo] common. sql onerror: continue 
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[echo] Userid: peisel 
[echo] SysUserld: 

[echo] dbCommonUserld: ${dbCommonUserId} 

[sql] Executing file: 

/u/peisel/Migration/DB/upgradeSchema612.sql 

[sql] 372 of 372 SQL statements executed successfully 

BUILD SUCCESSFUL 
Total time: 47 seconds 


7.3.10 Migrating the Business Process Choreographer runtime data 

After migrating a cluster that has BPC configured, you might need to perform a 
one-time data migration of the runtime data before you start the migrated server 
or any migrated cluster member. This step is applicable only if you are migrating 
from versions earlier than Version 6.2.x. Because we are migrating from 
WebSphere Process Server V6.1 .2, we have to migrate the runtime data. 

This task can be accomplished by running the migrateDB.py script from one of 
the cluster nodes’ bin directory. In our example, we execute the migrateDB.py 
script in /was70conf i g/1 lcel 1 /l Inodea/AppServer/bi n. The command we use in 
our environment is: 

wsadmin.sh -conntype NONE -profileName default -tracefile 
migrateDB.py_trace -f 

/<wps_instal l_dir>/ProcessChoreographer/admin/migrateDB.py -cluster 
llclOl -dbSchema L1CELL -dbUser <dbuser> -dbPassword <dbpswd> 

Examine the generated tracefile to make sure the BPC runtime data migration 
completed successfully. Example 7-25 shows the generated trace file in our 
environment. 

Example 7-25 The generated tracefile for BPC data migration 

[4/19/10 17:35:43:349 EDT] 00000001 TablespaceMig I CWWBB0656I: 

'Table 1/7 100.0%' completed. 

[4/19/10 17:35:43:663 EDT] 00000006 TablespaceMig I CWWBB0656I: 

'Table 6/7 100.0%' completed. 

[4/19/10 17:35:51:144 EDT] 00000000 TablespaceMig I CWWBB0647I: 
Tablespace migration successfully completed. 

[4/19/10 17:35:51:180 EDT] 00000000 DataMigration I CWWBB0651I: Data 
migration finished successfully. 
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The migrateDB.py script migrates the data related to BPEL and human tasks 
instances running in the source Version 6.1.2 environment. Migrating runtime 
data allows these instances to be valid after the migration. Users can work on 
these instances in the target Version 7.0 environment after the migration. 


Note: 

► Migration of runtime data should be run only once from one of the nodes. It 
should be run after migration and before you start any cluster members. 

► The time required to complete this step depends on the database content. 
Refer to the Technote “Complementary data migration documentation”, 
which can be found at the following address: 

http://www-01.ibm.com/support/docview.wss?rs=2307&uid=swg2 1327385 


7.3.1 1 Start the migrated environment 

After migrating the BPC runtime data, perform the following steps before starting 
the migrated nodes and application servers in the target environment: 

1 . Before starting the migrated primary node, the start JCL procedures in your 
JCL procedure library need to be updated for the primary node. Because the 
Version 7.0 start procedures have a different format than Version 6.x, the old 
Version 6.1 .2 procedures need be replaced: 

a. Locate the BBOMCPY1 job in the PDS where the jobs that were used for 
creating the primary node were stored. 
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In our environment, we found the job in the WPSCFG.NODEAV7.0.CNTL 
PDS (Figure 7-81). 


VIEW 

Command 


==MSG> 

==MSG> 

000001 

000002 

000003 

000004 

000005 

000006 

000007 

000008 

000009 

000010 

000011 

000012 

000013 

000014 

000015 


WPSCFG . N0DEAV7 . CNTL (BB0MCPY1) - 01.00 Columns 00001 00072 

===> submit Scroll ===> PAGE 

***************************** Top of Data *****************************: 
-Warning- The UNDO command is not available until you change 
your edit profile using the command RECOVERY ON. 

/ /BB0MCPY1 JOB (999, P0K) , ' WPS SETUP' , CLASS=A, REGI0N=0M, 

// MSGCLASS=H, N0TIFY=8tSYSUID 

/* JOBPARM S=SC61 

//* 

//C0PY1 EXEC PGM=IEBCOPY 


//* Copy customized members to the installation proclib 
//SYSPRINT DD SYS0UT=* 

//INPUT DD DISP=SHR, 

// DSN=WPSCFG . N0DEAV7 . CNTL 

//OUTPUT DD DISP=SHR,DSN=SYS1. PROCLIB 

//SYSIN DD * 

C INDD=INPUT, 0UTDD=0UTPUT 
S M= ( (BB0PDMN3, L1DEMNA, R) ] 

S M= ( (BB0PASR2, L1ASRA, R) 1 
S M= ( (BB0PACR2, L1ACRA, R] 1 


Figure 7-81 The BBOMCPY1 job for the primary node 
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b. Submit the BB0MCPY1 job (Figure 7-82). Because we use the same JCL 
start procedure names in Version 6.1.2 and Version 7.0.0, the 
BBOMCPY1 job will overwrite the existing JCL start procedures in your 
JCL procedure library. 


VIEW WPSCFG . N0DEAV7 . CNTL (BB0MCPY1) 

Command ===> submit 


01.00 


Columns 00001 00072 
Scroll ===> PAGE 


****** ***************************** Top of Data *******************: 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BB0MCPY1 JOB (999, P0K] , ' WPS SETUP' , CLASS=A, REGI0N=0M, 
000002 // MSGCLASS=H,N0TIFY=&SYSUID 

000003 /* J0BPARM S=SC61 
000004 //* 

000005 //C0PY1 EXEC PGM=IEBC0PY 

000006 //* Copy customized members to the installation proclib 
000007 //SYSPRINT DD SYS0UT=* 

000008 //INPUT DD DISP=SHR, 

000009 // DSN=WPSCFG . N0DEAV7 . CNTL 

000010 //OUTPUT DD DISP=SHR, DSN=SYS1. PROCLIB 

000011 //SYSIN DD * 

000012 C INDD=INPUT, 0UTDD=0UTPUT 
000013 S M= ( (BB0PDMN3, L1DEMNA, R) ) 

JOB BB0MCPY1 (J0B24550) SUBMITTED 


Figure 7-82 Submit the BBOMCPY1 job 


c. Wait until the console shows that the BBOMCPY1 job has finished 
(Figure 7-83). 


17.51.22 J0B24550 $HASP165 BB0MCPY1 ENDED AT WTSCPLX1 


Figure 7-83 The finished BBOMCPY1 job 
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d. Check the BB0MCPY1 job status via SDSF in an TSO session 
(Figure 7-84). 


IEB167I FOLLOWING MEMBER (St COPIED FROM INPUT DATA SET REFERENCED BY INPUT 


IEB155I L1AARA 
IEB155I L1ACRA 
IEB155I L1ADMSH 
IEB155I L1ASRA 
IEB155I L1DEMNA 


HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB1098I 5 OF 5 MEMBERS COPIED FROM INPUT DATA SET REFERENCED BY INPUT 
IEB144I THERE ARE 821 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY OUTPUT 

IEB149I THERE ARE 428 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY 

IEB147I END OF JOB - 0 WAS HIGHEST SEVERITY CODE 
Figure 7-84 Check the BBOMCPY1 job status via SDSF 


2. Before starting the migrated secondary node, the start JCL procedures in 
your JCL procedure library also need to be updated: 
a. Locate the BBOMCPY1 job in PDS where the jobs that were used to 
create the secondary node were stored. In our environment, we found it in 
the WPSCFG.NODEBV7.0.CNTL PDS. 


VIEW WPSCFG . N0DEBV7 . CNTL (BB0MCPY1) - 01.00 

Command ===> submi t 


Columns 00001 00072 
Scroll ===> PAGE 


****** ***************************** Top of Data *******************> 
==MSG> -Warning- The UNDO command is not available until you change 
==MSG> your edit profile using the command RECOVERY ON. 

000001 //BB0MCPY1 JOB [999, POK) , ’ WPS SETUP' , CLASS=A, REGI0N=0M, 
000002 // MSGCLASS=H, NOTIFY=&SYSUID 

000003 /* JOBPARM S=SC61 
000004 //* 

000005 / /C0PY1 EXEC PGM=IEBCOPY 

000006 //* Copy customized members to the installation proclib 
000007 //SYSPRINT DD SYS0UT=* 

000008 //INPUT DD DISP=SHR, 

000009 // DSN=WPSCFG . N0DEBV7 . CNTL 

000010 //OUTPUT DD DISP=SHR, DSN=SYS1. PROCLIB 

000011 //SYSIN DD * 

000012 C INDD=INPUT, 0UTDD=0UTPUT 
000013 S M= ( (BB0PDMN3, L1DEMNB, R) ) 

000014 S M= ( [BB0PASR2, L1ASRB, R) ) 

000015 S M= ( (BB0PACR2, L1ACRB, R) ) 

Figure 7-85 The BBOMCPY1 job for the secondary node 


b. Submit the BBOMCPY1 job in WPSCFG. NODEBV7.0.CNTL. 
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c. The console shows that the BBOMCPY1 job finished (Figure 7-86). 


17.53.07 J0B24551 $HASP165 BB0MCPY1 ENDED PIT WTSCPLX1 


Figure 7-86 The finished BBOMCPY1 job 

d. Check the BBOMCPY1 job status via SDSF in a TSO session 
(Figure 7-87). 


IEB155I L1AARB HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1ACRB HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1ADMSH HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1ASRB HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB155I L1DEMNB HAS BEEN SUCCESSFULLY COPIED AND IS A NEW NAME 

IEB1098I 5 OF 5 MEMBERS COPIED FROM INPUT DATA SET REFERENCED BY INPUT 

IEB144I THERE ARE 820 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY OUTPUT 

IEB149I THERE ARE 428 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY 

IEB147I END OF JOB - 0 WAS HIGHEST SEVERITY CODE 

Figure 7-87 Check the BBOMCPY1 job status via SDSF 


3. Start the primary and secondary nodes in the target environment. 

4. Start the application servers. 

5. Check for any errors in the server logs. 

7.3.12 Apply the adapter fix for running Version 6.1.2 adapters on 
WebSphere Process Server V7.0 

If your applications deployed on the source environment included the 
Version 6.1 .x and Version 6.2.x adapters, you need to apply the mandatory 
adapter fix for running Version 6.1 .x and Version 6.2.x adapters on WebSphere 
Process Server V7.0. 

For more information about the mandatory adapter fix and the instructions for 
how to apply them in the target environment, refer to 5.3.3, “Adapter migration 
considerations” on page 146. 
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7.4 Post-migration verification 


This section describes the steps for performing the post-migration verifications. 
We examine the target environment and verify if the migration process has 
successfully created the corresponding objects in the target environment. 

You will, in the target environment: 

1 . Verify that the profiles are properly created. 

2. Verify that the deployment environment is migrated. 

3. Verify that the system and user applications are migrated. 

4. Verify that the failed events generated in the source environment are migrated 
to the target environment. 

5. Verify that the pending BPEL and human tasks instances are migrated to the 
target environment. 

The items listed in this section were verified in our target environment on z/OS. 

Verify the target software versions after migration 

Log into the administrative console of the target environment, and you can see 
the target software versions after migration (Figure 7-88). 



Figure 7-88 The target software versions after migration 


Verify the log files 

After starting the target environment, you should first check the SystemOut . 1 og 
files for each server. On each machine, navigate to the 
<target _profile_root>/'\ogs/<Server_Name> directory and check 
SystemOut.log. There should be not fatal errors and similar messages. 

Check the messaging engine’s status 

Check the messaging engine’s status to ensure that all the messaging engines 
are running. Perform the following steps: 

1 . Log in to the administrative console. 
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2. Navigate to Service integration ->• Buses and click one of the bus names 
(for example, BPC.I1 cell. Bus). 

3. Select Topology ->• Messaging engines. 

4. The messaging engine should be in the started status (Figure 7-89). 



5. Perform steps 1 on page 438 through 4 to check the messaging engine’s 
status for all the other buses. 

6. If any of the messaging engines are not in the started status, check 
SystemOut.log of the corresponding application server for the root cause. 

Verify the cell topology after migration 

Open the administrative console and see if the source environment is migrated to 
the target environment as is. The cell topology is the same as in the source 
environment, as shown in Figure 7-90. 


Local Topology 

Cell 

B UdOl 

□ & Nodes 

FI (J llnodea CND 7.0.0.7, Proces 



□ £3, Cluster members 
IldOll 

FI l« llnodeb fND 7.O.O.7. Proces 



Cluster members 
^j) Help 12 


Figure 7-90 Cell topology 
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Verify the enterprise applications 

You can check the status of the enterprise applications, including the system and 
sample applications, in the administrative console. If there are running instances 
of the old predefined human task applications, they are not uninstalled during 
migration, which means that after migration, both the new and old versions of the 
predefined human task applications are in your system. 


Note: If any applications are not in the started status, check the 

SystemOut . 1 og file of the application server and the previous migration log file. 



Figure 7-91 Verifying the enterprise applications 

Verify the process instances 

If you have long running BPEL instances left before migration, you can log in to 
Business Process Choreographer Explorer to check the legacy instances by 
performing the following steps: 

1 . Log in to the Business Process Choreographer Explorer at 
http : //<host>: <port>/ bpc. 
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2. Navigate to Process Instances -» Administrated By Me. We can see all of 
the legacy BPEL instances (Figure 7-92). 


Process Instances for Process Templates 

Use this page to work with process instances that belong to specific process templates. [E 


| Migrate | Terminate | Delete | View Process State | Refresh 
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□ 

□ 

□ 

□ 

□ 

□ 

□ 
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□ 

□ 


Process Instance Name 0 


Process Template Name 


_PI: 90030127. def7578f.dffbf3f6.96ed0084 
_PI: 90030127. def66d7f.dffbf3f6.96ed0063 
_PI: 90030127. def5f30b.dffbf3f6.96ed0042 
.PI : 90030127. def53c70.dffbf3f6.96ed0021 
.PI: 90030127. deecb5a3.dffbf3f6.96ed0000 
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_PI:90030127.del0a043.dffbf3f6.9393007f 
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_PI: 90030127. del0033e.dffbf3f6. 93930041 
_PI: 90030127. de0fl376.dffbf3f6. 93930022 
_PI: 90030127. ddf0fca7.dffbf3f6. 3076027a 
_PI: 90030127. dde92381.dffbf3f6.3076023f 
_PI: 90030127. dde8e08d.dffbf3f6. 30760204 
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.PI: 90030127. dde8090a.dffbf3f6. 30760153 
.PI: 90030127. dde7bb36.dffbf3f6. 30760118 
.PI: 90030127. dde770ba.dffbf3f6.307600dd 
_PI: 90030127. dde7218a.dffbf3f6.307600a2 
_PI: 90030127. dde62289.dffbf3f6. 30760066 
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Figure 7-92 Legacy BPEL instances 


Verify Business Rule Manager 

Please verify that the business rules can be viewed and edited in the Business 
Rule Manager of the target environment by performing the following steps: 

1 . Log in to the Business Process Choreographer Explorer at 
http : //<host>: <port>/ br. 

2. Navigate to Business Rule Groups. 
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3. Expand one of the business rules (for example, RatingService -» 
performRiskRating ->• performRiskRating) and check the details 
(Figure 7-93). 


performRiskRating - Decision Table 



General Information 

Last Published Apr 8, 201 0 1 0:41 (Local Time) 

Description 


Decision Table 


Input. VINLookupSt at us.toUpperCaseO •> 4 
Input. Credit Score ( 

"NOT CLEAN" 

Output.RiskRatingScore 4 

>=720 

"Medium" 

>=580 and <720 

"High" 

<580 

"High" 


Figure 7-93 Business Rule Manager 


Verify the failed events 

If there are WebSphere Process Server failed events left before migration, check 
those failed events from the administrative console to make sure no failed events 
are lost during migration. 

Perform the following steps: 

1 . Log in to the administrative console at http://</?osf>;<porf>/ibm/console. 

2. Navigate to Integration Applications -» Failed Event Manager. 

3. Check the recovery sub-system status and application server version 
information at the right-top corner. 


About your failed event manager 

+ The Recovery sub-system is enabled . 
Total failed events 


IBM WebSphere Application Server for z/OS, 7.0.0.7 
Build Number: wps0947.04 
Build Date: 11/25/09 

Figure 7-94 Recovery sub-system status 
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4. Click Get all failed events, and you should see all of the legacy failed events 
there. In the failed event list, we can see that more failed events (for example, 
the failed event from the BPC module) are shown. This is a new feature in 
WebSphere Process Server V7.0. The failed event manager also displays the 
failed event from the BPC application. 



Figure 7-95 Failed events after migration 
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5. Check the first one of these failed events (Figure 7-96). 
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6. Check the business data of the first failed event (Figure 7-97). 



Figure 7-97 The business data of the first failed event 

The content and business data of this failed event remain the same after the 
migration. 


7.5 Troubleshooting 

In this section, we describe the issues we encountered during our migration 
procedure. 

The zWPSConfig.sh script failed with a RC=2048 

The zWPSConfig.sh script fails and produced the RC=2048 error. 

Symptom 

When you run zWPSConfig.sh for the deployment manager when adding 
WebSphere Process Server to the deployment manager in Version 7.0, 
zWPSConfig.sh failed with a RC=2048 error. 

In the log file at 

/was70config/l lcel 1 /I ldmnode/DeploymentManager/logs/manageprofi les/defa 
ul t_create.log, there is no clear cause, but in the . ./manageprofi les/defaul t 
directory, first.ant.log showed a java.langOutOfMemoryError error. 

Root cause 

Both these problems occurred because the .profile of the user submitting the job 
contained _BPX_SHAREAS=YES. Refer to the following Technote for more 
information: 

http : //www. ibm.com/support/docview.wss&uid=swg2 1377885 

Solution 

Make sure /etc/prof i 1 e has _BPX_SHAREAS=NO set. Make sure that the .profile of 
the user running the job has _BPX_SHAREAS=NO set, or comment out 
_BPX_SHAREAS=YES .Unsati sf i edLi nkError for the starting node. 
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UnsatisfiedLinkError error when starting a node 

There is an Unsati sf i edLi nkError error when starting a node. 

Symptom 

When starting nodes on z/OS, a SqlException exception with a 
java. lang. UnsatisfiedLinkError is thrown out: 

java.sql .SQLException: [jcc] [10389] [12245] [3.58.90] Failure in loading 
native library db2jcct2zos_64, java. lang. UnsatisfiedLinkError: 
/pp/db2v9/D100210/db2910_jdbc/lib/libdb2jcct2zos_64.so (EDC5205S DLL 
module not found. (errno2=0xC40B0025)) : ERR0RC0DE=-4472, 

SQLSTATE=nul 1 DSRA0010E: SQL State = null. Error Code = -4,472 

Root cause 

The current syntax for PATH and LIBPATH does not allow you to add MVS™ data 
sets to these variable settings. 

Solution 

If you are familiar with running a program in a UNIX shell, the kernel looks for the 
program you want to run in the list of directories defined to your PATH or LIBPATH 
environment variable settings. In z/OS UNIX System Services, this same concept 
applies for programs that reside in the z/OS UNIX System Services file system. 
However, there are some special things that we have to do to access products 
that ship their programs (load modules) in MVS data sets, such as DB2. 

The order of search for MVS load modules is STEPLIB/JOBLIB, LPA list, and 
then LNKLST. STEPLIB/JOBLIB are searches done at the TSO user or batch job 
level, while LPA and LNKLST are searches done at the system level. 

DB2 ships some of its programs and executables in the z/OS UNIX System 
Services file system and some others in MVS data sets. The current syntax for 
PATH and LIBPATH does not allow you to add MVS data sets to these variable 
settings. 

z/OS UNIX System Services has a special file attribute called an external link 
that allows a file to link to an object outside of the z/OS UNIX System Services 
file system. In this case, it allows access to MVS load modules stored in an MVS 
data set. 
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For example, if we display one of the DB2 programs in the z/OS UNIX System 
Services file system, we see that the external link bit is on and the contents of the 
link points to a member of a MVS data set called DSNAQJL2 (Example 7-26). 

Example 7-26 External link setting in the symbolic link attributes 
] Symbolic Link Attributes 

Pathname : /pp/db2v9/D100210/db2910_jdbc/l ib/1 ibdb2jcct2zos.so 
External link . . : 1 

File size : 8 

File owner : R00T(0) 

Group owner . . SYS1(0) 

Last modified . . 2007-03-21 15:06:10 

Last changed . . . : 2007-03-21 15:06:10 
Last accessed . . : 2010-02-19 12:48:43 

Created : 2007-03-21 15:06:10 

Link count . . . . : 1 
Device number . . : D7 
Inode number . . . : 4 
] Symbolic Link Attributes 

Pathname : /pp/db2v9/D100210/db29 10_jdbc/l ib/1 ibdb2jcct2zos.so 
External link . . : 1 

File size : 8 

File owner : R00T(0) 

Group owner . . .: SYS1(0) 

Last modified . . .: 2007-03-21 15:06:10 
Last changed . . . : 2007-03-21 15:06:10 
Last accessed . . : 2010-02-19 12:48:43 

Created : 2007-03-21 15:06:10 

Link count . . . . : 1 
Device number . . : D7 
Inode number . . . : 4 

Seclabel : 

Symbolic link contents: 

More: 

DSNAQJL2 


DSNAQJL2 happens to be a MVS load module that resides in the 
DB9K9.SDSNLOD2 data set. The following error says that WebSphere Process 
Server tried to execute libdb2jcct2zos.so (external link to DSNAQJL2) and could 
not find it: 

com.ibm.db2.jcc.am.SqlException: [jcc] [10389] [12245] [3.58.90] Failure 
in loading native library db2jcct2zos, java.lang.UnsatisfiedLinkError: 
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/pp/ db2v9/D1002 10/ db2910 _j dbc/1 i b/1 i bdb2jcct2zos . so (EDC5205S DLL 
module not found. (errno2=0xC40B0025)) : ERR0RC0DE=-4472, SQLSTATE=nul 1 

The fix is to add the following STEPLIBs to all the WebSphere Process Server 
procedures that point to the DB2 libraries: 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 

In our z/OS environment, we performed the following steps: 


Note: LI is the CELL description. If you have any other cell names, change LI 
to your cell name. 


1 . Open and browse to SYS1 .PROCLIB. 

2. For the deployment manager: 

a. Stop your environment completely. 

b. Search for DMGR procs, such as LI DCR and LI DSR. 

c. Add the STEPLIB to the procedure, for example, for 
SYSI.PROCLIB(LIDCR): 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 

i.e. for SYS1 . PROCLIB (LI DSR) : 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 

d. Save the procs for your DMGR. 

3. For the managed node: 

a. Search for the node’s procedures, for example, for NodeA, LI ACRA, 
L1ASRA, and L1AARA. 

b. Add the STEPLIB to the procedure. For example, add the following lines to 
SYS1 ,PROCLIB(L1 ACRA): 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 

i.e. for SYS1 . PROCLIB(LIASRA) : 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 
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i.e. for SYS1 . PROCLIB(LIAARA) : 

//STEPLIB DD DISP=SHR,DSN=DB9K9.SDSNEXIT 
// DD DISP=SHR,DSN=DB9K9.SDSNL0AD 

// DD DISP=SHR,DSN=DB9K9.SDSNL0D2 

Failed to initialize cursor error when starting server 

There was a failed to initialize cursor error when the server started. 

Symptom 

After migration, you see the following exception thrown when starting the 
application servers. This can occur if you have used JDBC adapters in your 
source environment: 

BB000220E: CNTR0020E: EJB threw an unexpected (non-decl ared) exception 
during invocation of method 

"transactionNotSupportedActivitySessionNotSupported" on bean 
"BeanId(ITSO_med_vlApp#ITSO_med_vlEJB. jarlModule, null)". Exception 
data: com. i bm. websphere. sea. ServiceRuntimeExcept ion: DataBinding 
Exception thrown in J2CMethodBindingImpl .invoke() 
commonj .connector. runtime. DataBindingException: Failed to initialize 
cursor at 

com. i bm.ws .sea. bi ndi ng. j2c . J2CMethodBi ndi nglmpl . i nvoke(J2CMethodBi ndi ng 
Impl .java: 1447) 

Root cause 

Your applications deployed on the source environment included the Version 6.1 .x 
or Version 6.2.x adapters. 

Solution 

Apply the mandatory adapter fix for running Version 6.1 .x and Version 6.2.x 
adapters on WebSphere Process Server V7.0 to make them work in the target 
Version 7.0 environment. For the instructions about how to apply them in the 
target environment, refer to 5.3.3, “Adapter migration considerations” on 
page 146. 
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Part 3 


Appendixes 


In this part, we provide supplemental information related to the migration 
examples. 
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A 


Migration checklist 


This appendix contains a sample migration check list. It reflects the planning 
process used before performing the migration in Chapter 6, “Migrating BPM 
V6.1 .2 to WebSphere Dynamic Process Edition V7.0” on page 195. The check 
lists here are similar to those found in 1 .6, “Migration questionnaire” on page 21 . 
They have been modified to contain only the questions relevant to the migration 
scenario. 
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Migration check list for a distributed system 

These check lists (Table A-1 through Table A-1 1 on page 463) were created in 
preparation for the sample migration in Chapter 6, “Migrating BPM V6.1 .2 to 
WebSphere Dynamic Process Edition V7.0” on page 195. 


Table A- 1 Migration goals 


Migration goal questions 

Action 

Do you want to use the features or functions 
provided in Version 7.0 of the product? 

What are the features you want to use? 

No. Currently, no new features are planned. 
Only new applications will be developed and 
deployed using Version 7.0. We will prepare 
WebSphere Integration Developer V7.0 and 
import all the required applications for future 
updates. 

Do you want to be as up-to-date as possible with the 
latest of Business Process Management product 
versions and fixes? 

Yes. We plan to collect the latest Fix Packs 
required for Version 7.0 and any critical fixes. 

Are you migrating due to a current problem with any 
of the products? If so, what problem and what 
product? 

No. We do not have any current BPM issues. 

What are the other reasons for migrating? 

To be able to create new business applications 
that take advantage of new features in the 
product. 
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Table A-2 Migration experience 


Migration experience questions 

Action 

Is this your first migration project for your team? 

No. We have results from the test team to 
compare. We also have leading practices 
available to us (documented throughout 
Chapter 6, “Migrating BPM V6.1 .2 to WebSphere 
Dynamic Process Edition V7.0” on page 195). 

What WebSphere products have you migrated 
before? 

All WebSphere BPM products. 

What difficulties did you experience last time? 
What mitigation strategies are planned for this 
migration project? 

None. 

What leading practices from last time will you want 
to reuse in this migration project? 

We have documented best practices from the 
migration discussed in Chapter 6, “Migrating BPM 
V6.1.2 to WebSphere Dynamic Process Edition 
V7.0” on page 195. In particular, we plan to pay 
special attention to our readiness to roll back any 
changes before, during, or after migration. 

Who are the people with experience with 
WebSphere products, topology, customer 
applications, security strategy, and migration 
experience? 

WebSphere BPM subject matter experts with a 
wide range of experience in migration (BPM 
SMEs). WebSphere BPM test team members. 
Development teams. 

Table A-3 Migration time frame 


Migration time frame related questions 

Action 

What is the target date for beginning the 
migration project? 

March 29th, 2010. 

When should the migration project be 
completed? 

April 23rd. It is a simple migration. 

Do we have a go live date, dictated by the 
customer’s commitment to their customers? 

No. 

What is the maximum downtime that is allowed 
for the migration? 

Downtime is not an issue. 

There is a planning downtime of 2 days. 

Will the DBAs and security administrators and 
application experts be available during the 
downtime period? 

Yes. 
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Table A-4 What to migrate 


| Questions about what to migrate 

| Action | 

| Runtime migration j 

Do you have applications that can be migrated as 
is? 

Yes. A list of existing applications has been 
documented and the applications have been 
evaluated to ensure that they will continue to work 
as is in the new environment. 

Do you have the current and target environment on 
the same hardware? 

Yes. The same hardware will be used and the new 
Version 7.0 products have been installed. 

Do you have to migrate a deployment environment, 
including deployed applications? 

Yes. 

Have you verified that the operating system used, 
database used, and their release levels are 
supported by both the current and target 
environment? 

Yes. Minor updates have been identified and 
installed. 

Conclusion: This will be an ideal case for runtime migration. 

Applications to be migrated 

Do you have applications that can be migrated as 
is? 

Yes. 

Do you have long running business processes? 

Yes. 

Do you have human tasks? 

Yes. 

How many applications are used in the system? 

2. 

How many applications are business critical? 

2. 

How many applications can be deprecated? 

None. 

How many applications will have to be updated to 
use the new features of the product? 

None. 

How many WebSphere Business Monitor models 
are deployed? 

1. 

How many WebSphere Business Services Fabric 
associate applications are deployed? 

None. 

| Source migration j 

Do you need to migrate the application source? 

No. 

Are these user applications included in the 
production critical time line? 

Not applicable. 
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Questions about what to migrate 

Action 

Do you have deprecated features? The list is 
available at the following address: 
http : / /publ i b. boul der . i bm.com/infocenter/dmnd 
hel p/V7 . OrOmx/topi c/ com. i bm. websphere . wps . doc 
/doc/gmi g_deprecati onl i st . html 

Not applicable. 

Table A-5 System maintenance 


System maintenance questions 

Action 

Is the system maintained on a regular schedule? 

No. 

What is the schedule? 

Not applicable. 

How is the system shutdown? What is the 
procedure and in what order are the components 
shut down? 

We shut down the components down in the following 
sequence: 

1 . Dashboard clusters. 

2. Application clusters. 

3. Support clusters. 

4. Message engine clusters. 

5. Node agents. 

6. Deployment manager. 

How is the system restarted? What is the 
procedure and in what order are the components 
restarted? 

We start the components in the following sequence: 

1 . Verify that the database is available 

2. Start the deployment manager. Verify that start 
by checking SystemOut.log. 

3. Start the node agents. Verify. 

4. Start the message engine cluster. Verify. 

5. Start the support cluster. Verify. 

6. Start the applications cluster. Verify. 

7. Start the dashboard clusters. 

Will the DBA be available during this scheduled 
maintenance? Do we need any special security 
clearance to execute the database scripts? 

Yes, and no security clearance is required. 

Will the security administrator be available during 
this maintenance window? 

Yes. 

Will the network administrator be available and 
can the ports be opened during this period? 

Yes. 
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Table A-6 Resources 


Resource question 

Identified resource 

Resource availability 

Who will be the dedicated 
resource for the migration 
project? 

Migration project manager 

BPM SME team. 

Do you have reusable assets 
from previous migration efforts? 

Automated migration test bucket 

Yes. 

Who are the dedicated resources 
for the: 

Migration method 

BPM SME team. (Available) 

Migration testing 

BPM SME team. (Available) 

Environment creation 

BPM SME team (Available) 

Applications 

BPM SME team. (Available) 

Profiles 

BPM SME team. (Available) 

Database 

BPM SME team. (Available) 

Operating systems 

BPM SME team. (Available) 

Network and fire wall 

BPM SME team. (Available) 

Customer software process 

BPM SME team. (Available) 

Name of the migration expert or 
consultant 


BPM SME team. (Available) 

Hardware resource. 

(Verify that there is adequate 
hardware.) 

Cell name 

WDPECellOI. 

System type 

All are Windows systems 

Memory 

See “Hardware requirements” on 
page 219. 

Operating system 

Windows 2003 Standard Edition 
Service Pack 2. 

Disk space 

See “Disk space requirements” 
on page 221. 

Host names 

See Table 6-3 on page 200. 

Remote access capability 

Yes. 

Software licenses. 

For IBM products and others 

Arranged. 
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Table A-7 Product information 


Product 

Current version 

Target version 

WebSphere Dynamic Process Edition server 

Package not installed 

Version 7.0 

WebSphere Process Server 

Version 6. 1.2.3 

Version 7.0 

Associated (Process Server) WebSphere 
Application Server 

Version 6.1.0.23 

Version 7.0.0.0.7 + Feature 
Pack for XML 1 .0 

WebSphere Integration Developer 

Version 6.1.2 

Version 7.0 

WebSphere Business Modeler 

Version 6.1.2 

Version 7.0 

WebSphere Business Monitor 

Version 6. 1.2.5 

Version 7.0 

Associated (Monitor) WebSphere Application 
Server 

Version 6.1.0.17 

Version 7.0.0.0.7 + Feature 
Pack for XML 1 .0 

WebSphere Enterprise Service Bus 

Installed as part of 
WebSphere Process 
Server 

Installed as part of 
WebSphere Process 
Server 

Business Space 

Version 6.1.2 

7 

Database 

DB2 V9.5 

DB2 V9.5 


Table A-8 Product maintenance 


Product 

Fix Pack information 

WebSphere Dynamic Process 
Edition server 

7. 0.0.0. The Fix Pack was not available when we started the migration. 

WebSphere Process Server 

7. 0.0.0. The Fix Pack was not available when we started the migration. 

WebSphere Application Server 

Version 7.0.0.0.7 

WebSphere Integration 
Developer 

Version 7.0.0.0.0 

WebSphere Business Modeler 

Version 7.0.0.0.0 

WebSphere Business Fabric 

Version 7.0.0.0.0 

WebSphere Business Monitor 

Version 7.0.0.0.0 

WebSphere Enterprise Service 
Bus 

Version 7.0.0.0.0 

Business Space 

There is no separate interim fix or Fix Pack. It will be included in the 
base component. 
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Table A-9 System requirements 


Software type 

BPM product 

Detail 

Current 

version 

Target 

version 

Database 

WebSphere 
Process Server 

Common DB (WPRCSDB), 
BPC tables (BPEDB), 
Message Engine DB (MEDB), 
and 

Common Event Infrastructure 
tables (EVENT) 

DB2 V9.5 

DB2 V9.5 


WebSphere 

Business 

Monitor 

WebSphere Business Monitor 
database 

DB2 V9.5 

DB2 V9.5 

Operating 

system 

Server 

environment 

BPM runtime nodes 

Windows 
2003 Server 
Standard 
Edition with 
Service Pack 
2 

Windows 
2003 Server 
Standard 
Edition with 
Service Pack 
2 


Tooling 

Environment 

WebSphere Integration 
Developer 

Varies; 
installed on 
the 

developer 

workstations 

Refer to the 

following 

address: 

http://www- 

01.ibm.com/ 

software/in 

tegration/w 

id/sysreqs/ 


Database Node 

IBM DB2 

Windows 
2003 Server 
Standard 
Edition with 
Service Pack 
2 

Windows 
2003 Server 
Standard 
Edition with 
Service Pack 
2 
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Table A-10 Workload characteristics 


Category 

Characteristic 

Description 

Functionality 

Business Process Execution Language (BPEL). 

Yes. 


Number of long running processes. 

1. 


BPEL micro flows. 

No 


Human tasks. 

2 


Business State machines. 

No. 


SCA modules. 

Yes, 3. 


Maps. 

Yes. 


Mediations. 

Yes. 


Business rules. 

Yes. 


Common Event Infrastructure used for WebSphere 
Business Monitor. 

Yes. 


Common Event Infrastructure used for Business 
Process Choreographer Observer function. 

Yes. 


Other Common Event Infrastructure usage. 

No. 


Web Services. 

Yes 


Adapters. 

IBM WebSphere Adapter for 
JDBC V6.1.0.4. 


Other functions used. 

No. 

Interaction 

styles 

Web services: JMS. 

No. 

Web services SCA. 

Yes. 


Interactions: Synchronous? 

Yes. 


Interactions: Asynchronous? 

Yes. 

Dependencies 
and sharing 

Dependencies among deployed module? 

No. 

Do you use a shared library? 

No. 
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Category 

Characteristic 

Description 

Workload 

volume 

Number of new process instances started per 
second, minute, or day. 

N/A. 


Duration of average long running process instance. 

1 week. 


Number of users supported by the system. 

2. 


Number of transactions per second, minute, or day. 

Limited. 


Number of monitor models. 

1. 


Number of KPIs. 

10. 


Number of measures. 

5. 


Number of counters. 

1. 


Number of cubes. 

1. 


Amount of historical data. 

Limited. 


Usage of REST service. 

Yes. 


Dashboard usage. 

Yes. 


Other. 

No. 

Quality of 
service (QOS) 

Quality of service considerations. 

None. 

Current 
Performance 
tuning settings 

WebSphere Application Server. 
WebSphere Process Server. 
WebSphere Enterprise Server Bus. 
WebSphere Business Monitor. 
WebSphere Business Fabric. 

Other products. 

Referred to the performance 
team for handling. They will 
ensure that the target 
environment has compatible 
settings. 
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Table A-11 Topology 


Topology questions 

Detail 

Profile 

► What type of topology is used? 

► What are the profiles to be migrated? 

► What are the host names of each system in the topology? 

► What is the type of hardware used for each node? 

► Where are the backups for the current profiles? 

► Where are the backups for database backup? 

See 6.1.1, “Source 
environment overview” on 
page 1 96 for details about 
the topology to be 
migrated. 

See 6.1.4, “Node and host 
names” on page 200 for 
host, node, and profile 
names. 

The IT staff will evaluate 
the hardware on each 
system to determine if it 
meets the requirements. 
Backups for profiles and 
product databases are 
taken on a nightly basis 
and stored on a server 
external to the topology. 
Additional backups will be 
taken at each stage of the 
migration. 

Cluster 

► Do you have a WebSphere Process Server Support cluster? 
(name and nodes for cluster members) 

► Do you have a WebSphere Process Server Message Engine 
cluster? (name and nodes for cluster members) 

► Do you have WebSphere Process Server Application clusters? 
(name and nodes for cluster members) 

► Do you have a Monitor Support cluster? (name and nodes for 
cluster members) 

► Do you have a Monitor Message Engine cluster? (name and 
nodes for cluster members) 

► Do you have Monitor Application clusters? (name and nodes for 
cluster members) 

► Do you have Monitor Web clusters? (name and nodes for cluster 
members) 

See 6.1.1, “Source 
environment overview” on 
page 196. 

Security 

► What security strategy is used? 

Refer to your security 
department for handling. 
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Related publications 


The publications listed in this section are considered particularly suitable for a 
more detailed discussion of the topics covered in this book. 


IBM Redbooks 

For information about ordering these publications, see “How to get Redbooks” on 

page 469. Note that some of the documents referenced here may be available in 

softcopy only. 

► IBM WebSphere Business Process Management V6. 1 Performance Tuning, 
REDP-4431 

► WebSphere Business Process Management 6.2.0 Performance Tuning, 
REDP-4551 

► WebSphere Business Process Management V6. 1.2 Production Topologies, 
SG24-7665 

► WebSphere Business Process Management V7 Production Topologies, 
SG24-7854 

► WebSphere Business Process Management and WebSphere Enterprise 
Service Bus V7 Performance Tuning, REDP-4664 

► z/OS: WebSphere Business Process Management V7 Production Topologies, 
SG24-7831 


Online resources 

These Web sites are also relevant as further information sources: 

► Business Process Management Samples & Tutorials Version 7.0: 
http : //publ ib.boulder.ibm.com/bpcsamp/index.html 

► Dojo Toolkit: 

http: //www. dojotool kit.org/ 

► IBM Fix Central: 

http : //www. i bm. com/support/f i xcentral / 
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► IBM Installation Manager Support Portal: 

http://www-947.ibm.com/support/entry/portal /Overview/Software/Ration 
al /IBM_Instal 1 ation_Manager 

► IBM WebSphere Business Process Management Version 6.0 Information 
Center: 

http : //publ i b . boul der . i bm. com/i nfocenter/dmndhel p/v6rxmx/i ndex. j sp 

► IBM WebSphere Business Process Management Version 6.1 Information 
Center: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/v6rlmx/i ndex. jsp 

► IBM WebSphere Business Process Management Version 6.2 Information 
Center: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/v6r2mx/i ndex. jsp 

► IBM WebSphere Business Process Management Version 7.0 Information 
Center: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7.0r0mx/i ndex. jsp 

WebSphere Dynamic Process Edition 

► WebSphere Dynamic Process Edition Information Center: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
.ibm.wdpe.doc/Welcome/i c-homepage.html 

► WebSphere Dynamic Process Edition system requirements: 

http: //www-01 . i bm. com/software/i ntegrati on/wdpe/requi rements/ 

WebSphere Process Server 

► Complementary data migration documentation: 
http://www-01.ibm.com/support/docview.wss?rs=2307&uid=swg2 1327385 

► Fixes for WebSphere Process Server: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2307&ui d=swg27006649 

► Interim fixes for installing WebSphere Process Server V7. 0.0. 0.0: 
http: //www-01 . i bm. com/support/docvi ew.wss?ui d=swg21414253 

► java.Iang.OutOfMemoryError: PermGen space issues might occur when you 
use installation scripts: 

http: //www-01 . i bm. com/support/docvi ew.wss?ui d=swg21410474 

► Troubleshooting problems with the BBOWWPFC job: 

http: //www-01. ibm. com/support/docvi ew.wss?uid=swg21377885 
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► WebSphere Process Server Information Center for Multiplatforms: 

http : //publ i b.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm. websphere. wps .doc/wel come_wps . html 

► WebSphere Process Server Information Center for z/OS: 
http://publib.boulder.ibm.com/infocenter/dmndhelp/V7.0r0mx/index.jsp 
?topi c=/com. i bm. websphere .wps . z . doc/wel come_wpsz . html 

► WebSphere Process Server migration planning worksheet: 
http://www-01.ibm.com/support/docview.wss?rs=2307&uid=swg27015595 

► WebSphere Process Server system requirements: 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27006205 

WebSphere Integration Developer 

► WebSphere Integration Developer system requirements: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=2308&ui d=swg27006409 

WebSphere Business Modeler 

► WebSphere Business Modeler Basic V7.0 Information Center: 

http: //publ i b.boul der.i bm.com/i nfocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm . btool s .model er . bas i c .mai n . doc/wel come/dochome_bas . html 

► WebSphere Business Modeler Advanced V7.0 Information Center: 

http: //publ i b.boul der.i bm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm . btool s .model er . advanced .mai n . doc/wel come/dochome_adv . html 

► WebSphere Business Modeler system requirements: 
http://www-01.ibm.com/support/docview.wss?rs=2025&uid=swg27008331 

WebSphere Business Services Fabric 

► Fixes for WebSphere Business Services Fabric: 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27008650 

► WebSphere Business Services Fabric Information Center: 

http : //publ i b . boul der.i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. i bm.ws . fabri c . i cmaster . doc/i c-homepage.html 

► WebSphere Business Services Fabric system requirements: 
http: //www-01 . i bm. com/software/i ntegrati on/wbsf/sysreqs/ 
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WebSphere Business Monitor 

► Fixes for WebSphere Business Monitor: 

http: //www-01. i bm.com/support/docview. wss?uid=swg27010921 

► WebSphere Business Monitor Information Center: 

http : //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
. i bm . btool s . he! p .moni tor . doc/home/home . html 

► WebSphere Business Monitor system requirements (all versions): 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=802&context=SSSRR3&ui d= 
swg27008414 

► WebSphere Business Monitor V7.0 system requirements: 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=802&context=SSSRR3&ui d= 
swg27016838 

WebSphere Compass Server 

► WebSphere Compass Server Information Center: 

http : //publ i b . boul der . i bm.com/infocenter/dmndhel p/V7 . OrOmx/topi c/com 
. ibm. btool s.hel p. modeler. col lab. publ ish. doc/we 1 come/home. html 

► WebSphere Compass Server system requirements: 

http: //www-01 . i bm. com/support/docvi ew.wss?rs=2331&ui d=swg27008946 

WebSphere Enterprise Service Bus 

► Fixes for WebSphere Enterprise Service Bus: 

http : //www-01 . i bm. com/support/docvi ew. wss?ui d=swg27007485 

► WebSphere Enterprise Service Bus Information Center: 

http: //publ ib.boulder.ibm.com/infocenter/dmndhel p/V7 .OrOmx/topi c/com 
.ibm. websphere. wesb.doc/info/wel come.html 

► WebSphere Enterprise Service Bus system requirements (all versions): 
http: //www-01. ibm. com/support/docvi ew.wss?uid=swg270069 12 

WebSphere Adapters 

► Compatibility Matrix: WebSphere Business Integration Adapters and 
WebSphere Adapters (JCA): 

http : //www-01 . i bm. com/support/docvi ew. wss?rs=0&ql=compati bi 1 i ty+matr 
i x : &q2=compat i bi 1 i ty+matri x+adapters&q3=compat i bi 1 i ty+matri x : +Websph 
ere+Business+Integration+Adapters+and+WebSphere+Adapters&uid=swg2125 
2626&1 oc=en_US&cs=utf-8&cc=us&l ang=en 
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► Managing WebSphere Adapters more effectively through wsadmin in 
WebSphere Process Server: 

http : //I tsbwassOOl . sby . i bm. com/cms/devel operworks/websphere/1 i brary/ 
techarti cl es/1001_yu/1001_yu. html 

► WebSphere Adapters product documentation links: 

http : //www-01 . i bm. com/software/i ntegrati on/wbi adapters/1 i brary/i nfoc 
enter/i ndex.html #wsa70 

► WebSphere Adapters V6.1 fix list for WebSphere Integration Developer 
V6.1.2: 

http: //www-01. i bm.com/support/docview. wss?uid=swg27017302 

WebSphere Portal Server 

► WebSphere Portal Server system requirements: 

http: //www-01. i bm.com/support/docview. wss?uid=swg27007791 

WebSphere Application Server 

► Service Integration Bus Explorer: 

http://www.al phaworks . i bm. com/tech/si bexpl orer/downl oad 

► WebSphere Application Server V7.0 Information Center: 

http : //publ ib. boulder.ibm.com/infocenter/was inf o/V7 .OrO/i ndex. jsp 

► WebSphere Application Server system requirements: 
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27006921 
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